Does release.yml not run when v* tags are pushed?
#1970
-
|
I've noticed that all runs of the Is the tag being created in a way that is not considered a 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 |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 11 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. Edit: Experiments confirm that this is the cause. But the solution we are using (see comments below) differs from any of the possible solutions I had suggested in this post. 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.
-
This seems pedantic, but it turns out to be relevant in multiple ways, at least one of which is not obvious. I think you mean an incantation that triggers the After all tags are pushed, CSR checks if it is configured to create GitHub releases and, if so, it iterates through all tags and creates corresponding GitHub releases. Our Our Skippable side thoughts
Assuming you are talking about running the
Deleting the remote tag and then pushing it would work to trigger the I don't know what happens if we delete the tag on the remote once that GitHub release already exists. Especially if it is an annotated tag, there is no fundamental reason the GitHub release couldn't be reused. But I am not sure if it would be reused, or if the Also, I am not sure if the workflow would always get that far: if I would also worry about the possibility that other people's integrations could depend on tags for crates that have been published on crates.io continuing to exist once they have come into existence, at least for crates that have not been yanked. However, the gh --repo GitoxideLabs/gitoxide workflow run release.yml --ref "refs/tags/$tag_name"This assumes That command is longer and more complicated than it usually needs to be. But sometimes it does need to have all those parts:
I have not yet actually tested the above command. I am somewhat reluctant to do so, with that exact command operating on this upstream gh --repo EliahKagan/gitoxide workflow run ci.yml --ref refs/heads/main |
Beta Was this translation helpful? Give feedback.
-
Yes, that is true, my apologies for the ambiguity and the hassle this caused.
An interesting question - I haven't checked the code, but knowing Thanks also for sorting out the 'incantation' needed to |
Beta Was this translation helpful? Give feedback.
-
|
Something I had forgotten to reply to before:
As of my previous messages, I hadn't actually verified that pushing more than three tags doesn't create the events. (That is, I hadn't checked that the documentation was accurate.) I have since confirmed that this is so.
I don't think this caused any hassle. This is because, as I hinted but (I now realize) never made totally clear, I had to emphasize these distinctions for the next part of my comment anyway. That was my real motivation for including that first section. Thus, I think I would've said much the same things over much the same volume of text either way, just maybe in a different order.
Thanks--I think I might've simply been wrong that CSR does this. I was reading the code, but the exact form in which it passes the tags was not essential to the analysis for the matter here, so I don't do an experiment to check.
No problem! Unfortunately, I am not sure I was altogether correct about the best command. The reason is that I hadn't thought about the case where one might already be setting the In these cases, I think Anyway, I'm testing some things now and I hope to open a PR for this shortly. |
Beta Was this translation helpful? Give feedback.
-
|
I've opened #2077. |
Beta Was this translation helpful? Give feedback.
The cause
In
cargo-smart-release, theperform_releasefunction iterates through the crates that are to be published. One of the steps it does in each iteration is to try to create a tag and, if that succeeds, add it totag_names. After all crates have been processed, the collected tag names are pushed:This
push_tags_and_headfunction builds and runs a singlegit pushcommand. This command lists all the tags to be pushed:Thus, we push all the tags together. The GitHub Actions documentation on the
pushevent says: