Move Release Tag Creation/Push to After Successful Builds

[andremig-bentley]

Currently during a release, the release tag is created and pushed to github during the version bump step. In the case of failing builds during subsequent steps, the release tag may be created and pushed to github and then later need to be removed. Additionally, even on a successful release, the build step might take a significant portion of time before it passes and moves on to publish the release to npm. This means the release tag might be up and visible on github for a significant portion of time before it is actually available on npm.

To solve this issue, this PR moves the tag create and push steps out of version-bump.yaml into fast-ci.yaml which controls our build pipelines. The tag creation/push steps now occurs only after fully successful build steps and if the SHOULD_PUBLISH commit note is present (meaning it comes from the version bump pipeline and will be published to npm).

Open to discussion on final placement of the tag creation/push steps.

Additionally, a few quality-of-life upgrades to the pipeline are made within this PR. First, there was previously a manual review needed during the build step any time deprecation date comment changes were made during the version-bump step. This was to allow us to review those changes and look for errors as that logic was still not fully trusted. As it has now been proven successful, that manual check has been changed to only be present if a PR was created by the deprecation date comment logic which needs to be merged in. This will only happen if there are merge conflicts between master and the release branch due to changes made by the deprecation date logic. This should be rare, so the manual validation should not be needed the vast majority of the time.

Also, a 5 minute timeout and a retry was added to rush install and git checkout steps within the build pipeline. This way, if these steps hang as they have been occasionally doing recently, they will fail quickly and retry, so we won't have to wait an entire hour for the whole job to timeout if we don't catch it manually. A retry was also added to rush cover steps in the build pipeline to catch any flaky test failures.

[Copilot]

Pull Request Overview

This PR moves the git release tag creation and push operations from the version bump pipeline to the build pipeline to ensure tags are only created after successful builds. This prevents orphaned tags when builds fail and reduces the time gap between tag visibility on GitHub and package availability on npm.

• Removed tag creation and --follow-tags flag from version bump pipeline
• Added new CreateReleaseTag job in fast-ci pipeline that runs after successful builds
• Tag creation now only occurs when SHOULD_PUBLISH commit note is present

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
common/config/azure-pipelines/jobs/version-bump.yaml	Removed git tag creation and modified push commands to exclude tags
common/config/azure-pipelines/jobs/fast-ci.yaml	Added new job to create and push release tags after successful builds

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

Pull Request Overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[andremig-bentley]

In addition to moving the release tag creation/push, some QOL upgrades to the pipelines have been added to this PR. The PR description has been updated to detail those changes.

[DanRod1999]

I think i would prefer the tags be pushed during the iTwinjs package publishing step. However, I see that is in a completely different repo. I'm open to other opinions, and this is def an improvement. But I do think the best spot would be after everything is published to npm

[andremig-bentley]

But I do think the best spot would be after everything is published to npm

My original plan was to move it to be within the publishing pipeline, but I put it here for two main reasons, one being that the publishing pipeline is held within a different repo. Second, the step to publish to npm requires that the github tag already exists, that's (currently) how it knows what version to publish to npm. So, no matter what, posting the tag to github needs to happen before publishing it to npm. Either way, the order of operations would be:

1. Bump
2. Build
3. Release Tag
4. Publish to npm

So putting it here instead didn't change anything about the order that things were taking place. How important is it that releasing the tag happens in the publishing pipeline?

[DanRod1999]

Second, the step to publish to npm requires that the github tag already exists, that's (currently) how it knows what version to publish to npm

Did not know this. Fair point. Still not a huge fan of the build pipeline having unnecessary steps for pushing to GH, but for this case I can get over it lol. I'd rather have it here then in a second repo that I always forget about.

[andremig-bentley]

How important is it that releasing the tag happens in the publishing pipeline?

@MichaelSwigerAtBentley @hl662 @tcobbs-bentley Since you guys are also going to be dealing with these releases, do you have any input on this discussion? I want to make sure we're generally in agreement on this.

[tcobbs-bentley]

How important is it that releasing the tag happens in the publishing pipeline?

@MichaelSwigerAtBentley @hl662 @tcobbs-bentley Since you guys are also going to be dealing with these releases, do you have any input on this discussion? I want to make sure we're generally in agreement on this.

It should be possible to publish purely based on the version that happens to be in the package.json file at the time that npm publish happens. Something like this can be used to determine the package name and version:

pkgName=$(node -p "require('./package.json').name")
pkgVer=$(node -p "require('./package.json').version")

Having said that, not being a yaml expert, and also not being all that familiar with this pipeline, I'm not sure how reasonable it would be to move the npm publish before the GitHub tag creation.

[andremig-bentley]

It should be possible to publish purely based on the version that happens to be in the package.json file at the time that npm publish happens.

I'll look in to the possibility of getting the version number some other way and opening parallel PRs here and in the imodeljs-build-pipeline-scripts repo where the publishing pipeline yaml is held. After a bit more thought I think it's the stronger solution. I'll update this PR with what I find.