Conversation
Bug #1: If the tag doesnt exist in the checkout, we didnt try to to fetch it. This meant that when specifying a version tag `vX.Y.Z` would only work if the requested tag was created before the first time we use a custom runtime. This probably doesnt happen all that often but one can running into it in local development. Bug #2: We added a sanity check that makes sure a pipeline is really running the requested SHA. This works by embedding the SHA in the binary at build time and then matching it with the requested sha that gets forward at runtime by the pipeline manager. If there is a mismatch we know that there is an issue with the runtime version selection and abort. In this case we also aborted when a version tag was specified instead of the SHA because the manager was forwarding the tag which got matched with the SHA of the corresponding tag (and of course this didn't match). The fix is to resolve the tag to a SHA before forwarding it to the pipeline. Signed-off-by: Gerd Zellweger <mail@gerdzellweger.com>
mythical-fred
approved these changes
Mar 26, 2026
| @@ -1051,6 +1051,7 @@ async fn checkout_runtime_version( | |||
| "protocol.version=2", | |||
There was a problem hiding this comment.
Nit: commit subject says "fix bug" (singular) but the body describes two fixes. "fix two bugs" (matching the PR title) would be more accurate.
mihaibudiu
approved these changes
Mar 26, 2026
|
|
||
| /// We need to pass the actual revision SHA to the binary for verification, | ||
| /// so in case we have a version tag, we need to convert it to the sha. | ||
| pub async fn resolve_runtime_sha( |
Contributor
Author
There was a problem hiding this comment.
we test the feature already in CI every time we run something in the merge queue.. but we don't usually set tag names, just runtime SHAs so this bug fell through. It's not obvious how to test this part easily because it's not obvious a version tag in a test is compatible with the current runtime. This feature is also behind a feature flag.
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
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.
Bug #1:
If the tag doesnt exist in the checkout, we didnt try to to fetch it.
This meant that when specifying a version tag
vX.Y.Zwould only work if the requested tag was created before the first time we use a custom runtime. This probably doesnt happen all that often but one can run easily into it during local development.Bug #2:
We added a sanity check that makes sure a pipeline is really running the requested SHA. This works by embedding the SHA in the binary at build time and then matching it with the requested sha that gets forward at runtime by the pipeline manager. If there is a mismatch we know that there is an issue with the runtime version selection and abort. In this case we also aborted when a version tag was specified instead of the SHA because the manager was forwarding the tag which got matched with the SHA of the corresponding tag (and of course this didn't match).
The fix is to resolve the tag to a SHA before forwarding it to the pipeline.
Describe Manual Test Plan
Tested manually, this feature is behind an experimental flag.