automatically generate version suffixes #2709
Conversation
davidmrdavid
force-pushed
the
dajusto/add-automatic-version-suffix
branch
from
1123fd1 to
d16f78a
Compare
azure-pipelines-release-nightly.yml
Outdated
| variables: | ||
|
|
||
| - name: PackageSuffix | ||
| ${{ if ne(variables['Build.SourceBranchName'], 'dev') }}: |
There was a problem hiding this comment.
I suggest checking $(Build.Reason) instead of source branch:
https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml
Can differentiate PR and CI this way.
There was a problem hiding this comment.
I'll look into $(Build.Reason), good idea.
Though I just realized I made a mistake here - The nightly build should probably only build from dev anyways. So I should change to logic here so this is always a ci build.
| - name: PackageSuffix | ||
| # if source branch is not `dev` then we're generating a release based on a feature branch | ||
| # In that case, we populate the environment variable "PackageSuffix" accordingly | ||
| ${{ if ne(variables['Build.SourceBranchName'], 'dev') }}: |
There was a problem hiding this comment.
Same here, can check Build.Reason.
Release build can be manual queue and dev branch.
And does this build def get ran post merge? In which case that would be a ci build.
There was a problem hiding this comment.
Today, this pipeline only runs when manually triggered, so it does not run automatically post-merge. The nightly pipeline does run post-merge, but that's a different .yml.
In this case, since this pipeline is always manual - do you think still think it makes sense to check Build.Reason? In my mind, the Build.Reason for this pipeline is always: "Manual".
There was a problem hiding this comment.
If we you do the build reason calculation, that is a step towards getting rid of the separate nightly pipeline and using this one for that as well.
Also, this is used for PRs as well is it not? Build.Reason will show PR then.
|
Thanks @jviau - I agree it would be good to consolidate (and I agree it would be a good idea), but +1 to doing it later so we can benefit from the automation now. Thanks! |
Replaces: #2707
When making a private extension release, we manually add a version suffix to the package so that it can be distinguished from an official release.
This PR automates that process in 2 ways:
(1) the CI automatically adds a version suffix when the standard/manual release pipeline is triggered in a feature branch. The version suffix will be
-pr.<yyyymmdd.<buildRev>>where<buildRev>is an integer that increases every time the pipeline is triggered on a given day.(2) the CI automatically adds a version suffix when the nightly release pipeline is triggered. The version suffix will be
-ci.<yyyymmdd.<buildRev>>where<buildRev>is an integer that increases every time the pipeline is triggered on a given day.