Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pin CI runner images to explicit versions #507

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

alexcrichton
Copy link
Collaborator

CI is run infrequently enough on this repository that there's a nontrivial chance that GitHub updates the definition of ubuntu-latest for example between two CI runs. This can be confusing for contributors as PRs seemingly break CI when in reality they have nothing to do with the breakage and it's due to the image changing.

This PR pins all images to the definition of *-latest at this time. The one exception is that one builder was pinned to 22.04 and I'm going to update it to 24.04 here and see if I can't fix CI issues that come up.

This'll require explicit PRs to update these images in the future, but hopefully that's only once every few ~years so not too much of a burden.

CI is run infrequently enough on this repository that there's a
nontrivial chance that GitHub updates the definition of `ubuntu-latest`
for example between two CI runs. This can be confusing for contributors
as PRs seemingly break CI when in reality they have nothing to do with
the breakage and it's due to the image changing.

This PR pins all images to the definition of `*-latest` at this time.
The one exception is that one builder was pinned to 22.04 and I'm going
to update it to 24.04 here and see if I can't fix CI issues that come up.

This'll require explicit PRs to update these images in the future, but
hopefully that's only once every few ~years so not too much of a burden.
Surely if I keep making commits that say "another fix" eventually I'll
run out of fixes. Surely, right? I'd put this in limerick form to be
more amusing if someone comes to read this but I'm not clever enough to
do that, so instead I'll just abruptly
Copy link
Collaborator

@abrown abrown left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

-DWASI_SDK_INCLUDE_TESTS=ON
-DWASI_SDK_INCLUDE_TESTS=ON \
-DCMAKE_C_LINKER_DEPFILE_SUPPORTED=OFF \
-DCMAKE_CXX_LINKER_DEPFILE_SUPPORTED=OFF
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is need here and below?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately I believe so yeah. This layer is for the cmake build of wasi-sdk itself, aka when building tests. The cmake layer is then for the sub-cmake-builds of libraries like libcxx themselves. At least from CI it looked like both were necessary to get things passing when just using "clang" as the compiler.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants