Does release.yml not run when v* tags are pushed?
#1970
Replies: 2 comments 7 replies
-
|
Unfortunately, these don't run even though they should.
That's a good point, the regex should obviously match the tag name (and did before), which may indicate that the event is either not registered, or it's not the right event. But here comes a hot take: I know it just stopped working without obvious cause, or one could say, over time. What changes with time? The amount of tags, as there are more and more crates. On another note: Can it be that there is no CI job anymore that would be installing from crates.io? I think the current release may actually be broken now (and I am investigating if that's the case for everyone). |
Beta Was this translation helpful? Give feedback.
-
|
It is breaking the world - will have to yank everything. |
Beta Was this translation helpful? Give feedback.
-
This makes sense to me. All changes I have made to the release workflow (except maybe minor formatting changes? I'm not sure), I have tested in my fork. In my testing, I have always used the I've observed that, when pushing multiple commits in quick succession, at least when they are pushed to a PR opened on a separate repository, some commits do not trigger CI. (I observed this when using
My guess is that whatever broke did not keep Edit: I just checked and the CI jobs for that did run. But it seems we only have them for Windows. (They test several targets, but all are on Windows.) So if the
Maybe that is a factor that affects the rate limit in some way. But pushing tags that point to commits that are not in the history of the default branch does, in general, trigger the So I think the tags being on unmerged commits either has no effect here or the effect is small and not the primary cause.
Oddly enough, in EliahKagan/cargo-smart-release#12 (which is a test PR for a possible forthcoming change to But when I ran (The behavior of I don't know if that information will help or not, but I figured I'd mention it. |
Beta Was this translation helpful? Give feedback.
-
I see, thanks for investigating. This time, |
Beta Was this translation helpful? Give feedback.
-
I'm not clear on how that would work.
Why doesn't the current test of whether
What does Would we test by installing from the tip of the
The upgrade to 0.72.0 was in starship/starship#6699. That doesn't have any comments about a specific reason for upgrading; More importantly, I would not expect the version to be bumped in A more concrete reason for my skepticism is that installation of Edit: Running the same command on Windows 10 with In view of all that...
...I wonder if this can be leveraged to make something we can put in Edit 2: In case it is of interest, the code and exact (now yanked) versions where I had encountered the problem as mentioned in #1970 (reply in thread) can be seen in EliahKagan/cargo-smart-release#12, specifically in the second commit I pushed there, whose errors can be seen here on CI. I am guessing and hoping that whatever you observed with |
Beta Was this translation helpful? Give feedback.
-
The goal of such a test would be to find out if a new release breaks the previous release. Installing the latest (just released) release of Using a downstream program for installation that we know catches up with releases very quickly and that is ubiquitous, like
That is true. An alternative would certainly be to have a script that figures out the previous release of Regarding
For context, To sum it up, while we could install |
Beta Was this translation helpful? Give feedback.
-
The causeIn git::push_tags_and_head(&ctx.base.repo, &tag_names, options.clone())?;This for tag_name in tag_names {
cmd.arg(tag_name.as_bstr().to_str()?);
}Thus, we push all the tags together. The GitHub Actions documentation on the
So I think that's the cause of the problem. Possible solutionsMultiple tag pushesThe simple solution of pushing each tag individually may be slower, though that probably does not matter. Or it may hit other rate limits, which may matter. I am also not certain that it would be sufficient: it might be that pushes within a very short time of each other are also considered to be "at once" for this purpose when they occur in quick enough succession, or in large numbers, or in some combination of quick succession and large numbers. While it's probably okay to be slower--and even to run much slower by inserting delays between the pushes to avoid aggravating other rate limits--the bigger problem with making We could push in groupsIdeally, for gitoxide, assuming I am right that this is the cause of the problem, we would have two separate tag pushes when there are tags for multiple crates including
But How that could workBecause the There would be various design decisions to make about how the grouping should work, but I suspect that the simple approach of always having two groups--tags that match a (By matching a The alternative of using a different eventAnother possible solution, for But I don't favor this alternative, because while the However, it may be that I am not looking in all the relevant places, or that the documentation is incomplete. So I'll try to look into that further when I have time to pick this back up, before dismissing the use of the Wait, am I right about the cause?The cause seems pretty straightforward, yet you may have noticed I've been hedging in my wording. The reason is that, from this comment, it sounds like running From the wording in that comment, I can't tell if it was saying the problem had recently started or not. That comment was posted in connection with the release that accompanied #1342, but I don't know that I should take it to mean that this was the first time the workflow didn't run on the |
Beta Was this translation helpful? Give feedback.
-
|
That's a great find, thanks a million! I firmly believe that this worked at some point, so it be willing to believe that at some point they changed their rules about push-tag events. To me not creating individual events for a multi-tag push seems like a bug, but maybe it's more of a fix to another issue. Possibly people worked around rate limits that way and instead of fixing their rate limits they broke the API? I don't know. Something I do know is that there shouldn't be much time spent on working around that on the side of CSR. Something I could imagine doing, besides just manually triggering a release like before, is to have a script or Do you think it's worth pursuing a fix, and if so what could a minimal meaningful QoL improvement look like? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I've noticed that all runs of the
releaseworkflow seems to have been manually triggered, i.e. through theworkflow_dispatchevent. It also seems like creating thev*tag forgitoxidereleases does not trigger it. For example, as of this writing, it has not yet run for v0.43.0, even though the tag and the GitHub release (with no added assets yet) exist.Is the tag being created in a way that is not considered a
pushevent? I think even when a tag is created through the UI, it is a push event, but perhaps implicit tag creation due to the creation of a GitHub release does not do that--I am not sure. I believecargo-smart-releasecreates and pushes the tag, but that it creates the release first, at least in draft form. If the tag is implicitly created in connection with the GitHub release before any tag is explicitly created or before a local tag is pushed, then maybe that could cause this? I don't know.Also, is this general situation, where the workflow is only run manually, intentional? Or is the workflow being manually triggered as a workaround for the
pushtrigger not working?Beta Was this translation helpful? Give feedback.
All reactions