Open alexbde opened 3 years ago
KalleOlaviNiemitalo
commented
3 years ago I have seen in-progress build statuses posted to Bitbucket Server get stuck in a similar way. Those are implemented in cloudbees-bitbucket-branch-source-plugin or atlassian-bitbucket-server-integration-plugin, and not depend on checks-api-plugin at all. So I'm wondering if the problem might be in workflow-multibranch-plugin or in the Jenkins core.
KalleOlaviNiemitalo
commented
3 years ago And now there is https://github.com/jenkinsci/bitbucket-branch-source-plugin/pull/472 for fixing that in one plugin. Is it a coincidence or is someone reading my comments here? 😀 Let's see how it goes; maybe it is possible to use a similar solution in checks-api-plugin or github-checks-plugin.
alexbde
commented
3 years ago I can confirm that this also happens when a branch/PR is merged in the meantime :/
That's a great coincidence with the bitbucket plugin. But I just saw your comment, the same fix will not work for the github-checks-plugin. Do you already have an idea how to solve it?
alexbde
commented
3 years ago Hi again! Some additional information: I tested merging a PR during the current build and thought it is the same issue as if the branch was deleted in between. But I just realized the reporting of the COMPLETED status is not missing in this case, but failing because it reports the status to the shared pipeline repository instead:
This is kind of interesting, because I thought issues like that are fixed via #70. How can this still happen? 😕
KalleOlaviNiemitalo
commented
3 years ago Well, https://github.com/jenkinsci/github-checks-plugin/pull/70 tries GitHubSCMSourceChecksContext first, but I suppose GitHubSCMSourceChecksContext doesn't find anything if the branch has been deleted from the repository and Jenkins has switched the branch to NullSCMSource. And then it falls back to GitSCMChecksContext and finds the pipeline shared library.
alexbde
commented
3 years ago Sounds reasonable. If we're lucky the same fix will solve both issues.
So, I'm willing to help here. I had a look into the code base, but I'm not familiar enough with Jenkins plugin mechanisms to fully understand it. I wouldn't hesitate to file a PR, but only if it's helpful of course :D If I can support, just say a word.
KalleOlaviNiemitalo
commented
3 years ago I don't use github-checks-plugin myself and am not going to try to fix this.
alexbde
commented
3 years ago I don't use github-checks-plugin myself and am not going to try to fix this.
@KalleOlaviNiemitalo I thought you're a maintainer due to your understanding of the issue, but looks like I got that wrong, sorry for that!
Next steps for me: implement workaround via GitHub API (idea: calling the commits/${env.GIT_COMMIT}/checks_run endpoint and setting state to COMPLETED in pipelines deleting/merging the triggering branch). Have a look how the github-branch-source-plugin detects the commit sha and reports the status - looks like this is working fine in all situations (starting point).
KalleOlaviNiemitalo
commented
3 years ago @alexbde I studied the SCM selection logic in github-checks-plugin when I was working on a different plugin.
alexbde
commented
3 years ago Workaround time! As promised I implemented a workaround to deal with this issue. It's not beautiful, it's working.
Snippet for declarative pipeline that can be added after a stage/pipeline which deletes/merges the triggering branch:
post {
always {
// Begin of workaround to mitigate https://github.com/jenkinsci/github-checks-plugin/issues/196
script {
def buildResult = currentBuild.currentResult.toLowerCase().replace('unstable', 'neutral')
// @see https://docs.github.com/en/rest/reference/checks#list-check-runs-for-a-git-reference
def checkRuns = // curl GET <github-api>/commits/${env.GIT_COMMIT}/check-runs?check_name=Jenkins&status=in_progress
checkRuns.check_runs.each { checkRun ->
// @see https://docs.github.com/en/rest/reference/checks#update-a-check-run
// curl PATCH <github-api>/check-runs/${checkRun.id} -d {"conclusion": "${buildResult}"}
}
}
// End of workaround
}
}Note: it is no problem, if the delete/merge only happens conditionally, as the usual status check publishing at the end of the build run will just overwrite the workaround.
timja
commented
3 years ago Aren't you always setting the check_run to success there? even on failure?
alexbde
commented
3 years ago Aren't you always setting the check_run to success there? even on failure?
@timja That's true, thank you for the hint! It doesn't matter in my case because merging/deleting is always the last step. If it fails, the branch is still there and the failure will be reported via github-checks-plugin.
So, I'd rather hope for this issue getting fixed soon, instead of making this workaround beautiful. The important thing for me is, that builds are not shown as running for always.
But if somebody reads and wants to handle this: there are different post conditions, you don't need to use always, but could react to successful/failed builds: see Jenkins docs. As an alternative you could use the result of the currentbuild global var: currentBuild.currentResult. See <your-jenkins-host>/pipeline-syntax/globals for details.
Update: okay, solution with currentBuild.currentResult was really straightforward, I implemented it and adjusted the snippet above.
KalleOlaviNiemitalo
commented
3 years ago atlassian-bitbucket-server-integration adds the commit ID and repository info to the Run as an invisible BitbucketRevisionAction.
alexbde
commented
2 years ago Hi all! Any update on this? It is still an issue for us :/
timja
commented
2 years ago No one is actively working on the repo currently.
PRs are reviewed and merged, so anyone can contribute a fix if they wish.
We experience an issue with the status checks reporting:
Steps to reproduce:
mainwith commit shaaaaaaa, create new branchtest, also pointing toaaaaaatestvia github-branch-source-plugin and triggers build automatically[GitHub Checks] GitHub check (name: Jenkins, status: IN_PROGRESS) has been published.. Accordingly, the build status in GitHub UI is reported correctly and can be viewed at branchmainandtest(because they're both pointing to commitaaaaaa)testis deleted via GitHub API, e.g.[Pipeline] sh curl -s -X DELETE -u x-access-token:**** -H Accept: application/vnd.github.v3+json https://github.example.com/api/v3/repos/example-owner/example-repository/git/refs/heads/testExpected behaviour:
The status
COMPLETEDis reported to GitHub, e.g.:Actual behaviour:
The status
COMPLETEDis not reported to GitHub.This is not bad for the remote branch
test(because it was deleted anyhow), but the status check on the branchmainspins endlessly:Not sure if related: we're using two shared declarative pipelines for the build.
Versions