Skip to content
Open
Show file tree
Hide file tree
Changes from 8 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 38 additions & 0 deletions .github/PULL_REQUEST_TEMPLATE/security_fix.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
<!--
Please rename the PR to follow the following convention:
PR Title: "Security Fix: <Short Description of Changes>"

Please add the "security" label to the PR.
-->

## Security Fix

### Severity

- [ ] Critical
- [ ] High
- [ ] Medium
- [ ] Low

### Description

A clear description of the security issue being addressed.

### Root Cause

Brief explanation of what caused the security issue.

### Link to Security Notice

Link to CVE/GHAS notice.

### Solution

Describe the fix implemented and why this approach was chosen.

### Additional Notes

Any additional context or considerations for reviewers.

---
<!-- This PR will be automatically backported to supported release branches via Mergify due to the "security" label -->
17 changes: 17 additions & 0 deletions .github/mergify.yml
Original file line number Diff line number Diff line change
@@ -1,4 +1,9 @@
# Configuration file for mergify

# Branch variables for backport targets
latestMinor: &latestMinor "release/5.2.x"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. plz link to docs explaining the syntax
  2. how can we automate update this latest minor branch name every time we do a release?
  3. latest minor is not 4.9, its 4.11

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

disregard 2; i see its handled in ver bump pipeline

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re 1 - which syntax do you mean, the branch naming convention?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no the variable, &latestMinor

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its using YAML's anchors and aliases:
https://yaml.org/spec/1.2.2/#anchors-and-aliases
https://yaml.org/spec/1.2.2/#alias-nodes
https://support.atlassian.com/bitbucket-cloud/docs/yaml-anchors/

It seemed like a better solution to me than just having the release branches directly named in step, but it is a little more complicated. It can be changed to just:

backport:
    branches:
        - "release/5.2.x"
        - "release/4.11.x"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why wouldnt hardcoding these instead of adding it to another var that is only referenced once and needs to be updated not be easier?

Copy link
Contributor Author

@andremig-bentley andremig-bentley Oct 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it would be easier to just have them hardcoded, my main thinking was just clarity, as in what are these branches, why are we backporting to them specifically, etc. But, that can be taken care of with doc comments. In the latest commit, I've simplified it to hardcode the branch names, a simpler implementation with a doc comment is probably the better way to go.

previousMajor: &previousMajor "release/4.11.x"

defaults:
actions:
backport:
Expand Down Expand Up @@ -27,3 +32,15 @@ pull_request_rules:
message: |
This pull request is now in conflicts. Could you fix it @{{author}}? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

- name: Automatic backport for Security fixes
conditions:
- and:
- merged
- base=master
- label="security"
actions:
backport:
branches:
- *latestMinor
- *previousMajor
20 changes: 19 additions & 1 deletion common/config/azure-pipelines/jobs/version-bump.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -113,6 +113,10 @@ jobs:
# manually to be the most recent previous major release
# e.g. if this release is `release/5.0.x`, value in `gather-docs.yaml`
# should be `release/4.<whatever_last_minor_release_version_was>.x`
# additionally if major version bump, the `mergify.yml` also needs to be edited manually
# if this release is `release/5.0.x`,change the `latestMinor` variable to `release/5.0.x`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

comments are out of date

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated in most recent commit

# and the `previousMajor` variable to `release/4.<whatever_last_minor_release_version_was>.x`

if [ $((previousMinorVersion)) -lt 0 ]
then
echo "This is is a major release. Edit \"gather-docs.yaml\" manually."
Expand Down Expand Up @@ -254,8 +258,22 @@ jobs:
displayName: Get new version number
name: getVersion

# When creating a minor release, the NextVersion.md need to be cleared and the contents placed into a {Version Number}.md file
- ${{ if eq(parameters.BumpType, 'minor') }}:

# When creating a minor release, the mergify.yml file needs to be updated to change the "latestMinor" branch for security fixes
- bash: |
mergifyPath=".github/mergify.yml"
version=$(echo $(getVersion.version) | sed 's/\([0-9]*\.[0-9]*\)\.[0-9]*/\1.x/')
releaseBranch="release/$version"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we were to update 4.11 to 12, would this still work? It looks fine, but just double checking updating prev major won't cause unintended problems

Copy link
Contributor Author

@andremig-bentley andremig-bentley Oct 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there's a chance it would break with this current implementation. Currently it basically just takes the version created from the version bump step and sets the first release branch in the list to that value. If we were to run a version bump on release/4.11.x for a new minor, I think it would set 5.whatever.x to 4.12.x and leave 4.11.x there. There wouldn't be any problem with patches. Is there any precedent for us releasing a new minor on a previous major, though?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a fail safe, the most recent commit changed the logic so that the version-bump step looks at the major version number of the new version, and updates the release branch which starts with that same major version number. This means that if we were to release a new minor on a previous major version (4.11 -> 4.12), the bump would update the correct branch.

echo "Updating mergify.yml to use $releaseBranch as the recent minor branch for security fixes"

# Update the latestMinor variable in mergify.yml
sed -i "s|^latestMinor: \&latestMinor \"release/[0-9]*\.[0-9]*\.x\"$|latestMinor: \&latestMinor \"$releaseBranch\"|" "$mergifyPath"

displayName: Update mergify.yml for new minor release
condition: and(succeeded(), startsWith(variables['Build.SourceBranch'], 'refs/heads/release/'))

# When creating a minor release, the NextVersion.md need to be cleared and the contents placed into a {Version Number}.md file
- powershell: |
$sourceFile = 'docs/changehistory/NextVersion.md'

Expand Down