-
Notifications
You must be signed in to change notification settings - Fork 313
Refactor conditions for Prerelease and Release stages #2977
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
base: main
Are you sure you want to change the base?
Conversation
- Allow arbitrary branches to be manually built and live tested without being released - Only allow releases from manually queued runs of `main` or `hotfix/*`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR refactors the CI/CD pipeline conditions to improve branch management and release control by restricting releases to specific branches while allowing live testing on any branch.
- Reorders conditions to check branch restrictions before other release criteria
- Restricts releases to only
main
andhotfix/*
branches for better release governance - Updates comments to reflect the new condition ordering and branch restrictions
Co-authored-by: Copilot <[email protected]>
# 3. Not weekly build | ||
# 4. Manual trigger or force IncludeRelease | ||
- ${{ if eq(variables['System.TeamProject'], 'internal') }}: | ||
- ${{ if or(eq(variables['Build.SourceBranch'], 'refs/heads/main'), startsWith(variables['Build.SourceBranch'], 'refs/heads/hotfix/')) }}: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aren't branch specifics usually in ci.yml
? This feels much more strict.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a lot of rules here that should probably just go into the IncludeRelease
parameter. As is, the PR template passes "IncludeRelease: false" and all of the ci.ymls let it default to true. For some reason, we ignore IncludeRelease if the build was manually queued, which is what I want to avoid here....
Can you think of any reason to release a build that wasn't manually queued?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, but I also wonder why we don't support the usual release/
prefix. Or even feature/
, though we'd want to make sure those don't publish to crates.io and that would require more work than is in scope here or necessary for GA.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hallipr as we chatted I agree with Heath this is too strict. We should let you trigger from any branch. We still have the approval environment that will block anything from publishing until it is ready.
main
orhotfix/*