Run Jenkins stage after pipeline success independently - github

Question

So I have a groovy Jenkinsfile script that runs on my Jenkins server for pull requests. On my repos I have a protected master branch. I want my tests and stuff to run only on certain branches but what I want to happen is when the correct branch is detected it will attempt to merge the pull request automatically. The issue I'm getting is I need the pipeline job to report status success before this stage works. For example
pipeline {
agent none
options {...}
environment {...}
stages {
stage("1") {...}
stage("2") {...}
stage('Merge Pull Request') {
when {
allOf{
not { branch 'master' }
expression{env.CHANGE_TITLE.startsWith('branch title')}
}
}
agent {
docker {
label '...'
image '...'
}
}
steps {
touch "f.txt"
sh "echo \${GITHUB_TOKEN} > f.txt"
sh "gh auth --hostname <hostname> login --with-token < f.txt"
sh "gh pr merge -s ${env.CHANGE_URL}"
}
}
}
}
This works the way I want with the caveat that the merge occurs before the status is reported back so it fails because I'm trying to merge to a protected branch that hasn't received the success yet. Any idea on what I can do or how to trigger another job that is not downstream and waited on by this job to complete?

Answer 1

Presumably, you want the branch(es) to be protected so that manual merges cannot occur outside of the pipeline.
For this, I also presume you define a Required commit status check in your protected branch(es) settings.
By default, the pipeline will start the default 'pr-merge' status check at the beginning of the pipeline, and then mark it passed/failed at the very end. The PR Merge is denied because the required status check is not yet passed.
For your solution to work, The final stage ("Merge Pull Request") should first SET the desired status check to PASSED (via the GitHub API), and then make the PR Merge api call.
By the way, you can choose to use a different PR check than the one used by default in Jenkins, and name it what you want. This has the additional advantage than someone cannot circumvent your clever scheme by setting up a rogue Jenkins service with a no-op pipeline (that will mark the status check as "PASSED" automatically). It's not iron-clad, but it requires a bit more effort.