Add some infrastructure for keeping old CI working#10438
Merged
alexcrichton merged 1 commit intobytecodealliance:mainfrom Mar 20, 2025
Merged
Add some infrastructure for keeping old CI working#10438alexcrichton merged 1 commit intobytecodealliance:mainfrom
alexcrichton merged 1 commit intobytecodealliance:mainfrom
Conversation
This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
Member
Author
|
I've tested things locally except for the final bit of logic to file an issue, which I think I've fixed after testing locally as well. I'll manually trigger this CI run when this merges to ensure everything's working though. My hope is that 24.0.0 is probably broken at this time and we'll need to fix something so we should see an issue pop up. |
alexcrichton
commented
Mar 20, 2025
Comment on lines
+39
to
+45
| // We support two LTS channels 12 versions apart. If one is already included | ||
| // in the above set of 3 latest releases, however, then we're only picking | ||
| // one historical LTS release. | ||
| let mut lts_channels = 2; | ||
| if to_trigger.iter().any(|(major, _, _)| *major % 12 == 0) { | ||
| lts_channels -= 1; | ||
| } |
Member
Author
There was a problem hiding this comment.
This is technically somewhat inaccurate. If an LTS branch has been created, but not released, then we need to still look back 2 releases. The risk of that causing issues is pretty small though as that's a 2-week window and I otherwise don't know how to easily test for whether the latest branch has been released or not as part of this script.
fitzgen
approved these changes
Mar 20, 2025
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Mar 20, 2025
…10438) This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Mar 20, 2025
…10438) This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Mar 20, 2025
…10438) This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Mar 20, 2025
…10438) This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
abrown
pushed a commit
that referenced
this pull request
Mar 20, 2025
This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
abrown
pushed a commit
that referenced
this pull request
Mar 20, 2025
This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
alexcrichton
added a commit
that referenced
this pull request
Mar 21, 2025
This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
alexcrichton
added a commit
that referenced
this pull request
Mar 21, 2025
This commit is preparation for the infrastructure to be used when supporting [Wasmtime LTS releases][rfc]. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway. The general architecture here is: * A new `ci-cron-trigger.yml` workflow is added. * This new workflow runs once-a-week and runs a small script that triggers CI for all active release branches. * The main CI, `main.yml`, is updated to file an issue on failure when triggered in this fashion. While I was here I additionally removed the `schedule:` from the `main.yml` to instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs. [rfc]: bytecodealliance/rfcs#42
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Mar 21, 2025
Updates a condition from bytecodealliance#10438 to trigger historical release CI on manual trigger, not just the schedule.
github-merge-queue bot
pushed a commit
that referenced
this pull request
Mar 21, 2025
Updates a condition from #10438 to trigger historical release CI on manual trigger, not just the schedule.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This commit is preparation for the infrastructure to be used when supporting Wasmtime LTS releases. The goal here is to add some automation and infrastructure to perform a weekly build of all active release branches which will file an issue on failure. This should ideally keep branches up-to-date and ensure that we don't forget to backport any fixes to older branches. Or rather when we do forget to backport fixes this'll be a reminder to go do that anyway.
The general architecture here is:
ci-cron-trigger.ymlworkflow is added.main.yml, is updated to file an issue on failure when triggered in this fashion.While I was here I additionally removed the
schedule:from themain.ymlto instead fold the daily scheduling of CI runs into this new script as well. That way all our cron CI jobs are gated in workflows that require this exact repository meaning that forks won't be running cron jobs.