chore(e2e): Fix worker version e2e-docker-base-with-worker-version to account for 1.0 release#6588
Conversation
… account for 1.0 release
There was a problem hiding this comment.
Pull request overview
Updates the enos CI workflow to correctly select a “previous release line” Boundary worker Docker image tag for the e2e_docker_base_with_worker_version scenario, including handling the 1.0.0 release boundary.
Changes:
- Fetch full git history in the
enosjob checkout to allow tag-based version resolution. - Replace “decrement minor version” logic with tag scanning to find the prior release line version.
- Export the computed prior version as
ENOS_VAR_worker_versionfor the scenario.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| exit 1 | ||
| fi | ||
|
|
||
| IFS='.' read -r current_major current_minor current_patch <<< "$current_version" |
| echo "ENOS_VAR_worker_version=0.$ENOS_VAR_worker_version" >> "$GITHUB_ENV" | ||
| current_version_raw=$(./enos/support/boundary/boundary version | awk '/Version Number/ {print $3}') | ||
| current_version="${current_version_raw#v}" | ||
| current_version="${current_version%%[-+]*}" |
There was a problem hiding this comment.
It looks like this this handles boundary versions coming from boundary-enterprise (i.e. 0.21.2+ent), but I don't think we're handling this with tags?
There was a problem hiding this comment.
The current_version_raw outputs 0.21.0+ent line 275 takes out the +ent. Line 274 probably isn't needed though.
There was a problem hiding this comment.
Right. That's the output of boundary version. But when you're looking up the tags later on, boundary-enterprise has tags with v#.#.#+ent
There was a problem hiding this comment.
Ah yes. I'll test this in the ent branch as well to make sure I can get the right version. We handle adding the +ent in the enos scenario I'm pretty sure so it should strip the +ent from the git tags when it's parsing through that.
There was a problem hiding this comment.
I think I might be confusing myself.
- For this workflow, this probably works ok.
- We will need to update
enos-run-ent.ymlaccordingly. We should specifically match against +ent tags there as there may be some versions only available in enterprise.
There was a problem hiding this comment.
Pull request overview
Updates the Enos e2e workflow to compute a “previous worker version” based on git release tags, so e2e_docker_base_with_worker_version continues to work across the 1.0.0 release line transition.
Changes:
- Adjust checkout behavior in workflow jobs (setup job becomes shallow; enos job explicitly fetches full history).
- Replace “minor - 1” worker version derivation with logic that selects the latest tag from the previous release line (previous minor, else previous major).
- Add parsing/validation around the Boundary version string before selecting the previous version.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Updates the enos-run GitHub Actions workflow to compute the worker Docker image version for the e2e_docker_base_with_worker_version scenario by selecting the previous release line from git tags (handling the 1.0.0 -> 0.x.y transition), rather than decrementing a minor version number.
Changes:
- Adjusts
actions/checkoutsettings to (conditionally) fetch full history and tags for the worker-version scenario. - Replaces the worker-version derivation logic with tag-based semver parsing and selection of the prior release line.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot Autofix powered by AI <[email protected]>
moduli
left a comment
moduli
left a comment
There was a problem hiding this comment.
Reminder: There will need to be a follow-up to update this in enos-run-ent.yml. It will also need to account for using the -ent version of the tags.
Description
Change the logic for getting the version to taking current version - 1 to taking a list of versions and then finding the version before.
examples
0.21.3->0.20.2
1.0.0->0.21.3 (or whatever the last non 1.x.x version is)
PCI review checklist
Examples of changes to security controls include using new access control methods, adding or removing logging pipelines, etc.