Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature/324 | skip non PR notifications #451

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

sams-gleb
Copy link
Contributor

@sams-gleb sams-gleb commented May 25, 2021

Adding a checkbox to avoid overwriting of PR status by the branch build status. Should fix #324 . We had similar problems in our pipelines where branch build can be finished in the middle of running PR build thus allowing to merge un-tested changes into master

Your checklist for this pull request

  • [x ] Make sure you are requesting to pull a topic/feature/bugfix branch (right side) and not your master branch!
  • [ x] Ensure that the pull request title represents the desired changelog entry
  • [x ] Please describe what you did
  • [x ] Link to relevant issues in GitHub or in Jenkins JIRA
  • [x ] Link to relevant pull requests, esp. upstream and downstream changes
  • Did you provide a test-case? That demonstrates feature works or fixes the issue.

@sams-gleb sams-gleb force-pushed the feature/324-pr-notifications branch 2 times, most recently from 5b04669 to 66655e0 Compare November 23, 2021 09:48
@sams-gleb sams-gleb marked this pull request as ready for review November 23, 2021 09:52
@sams-gleb sams-gleb force-pushed the feature/324-pr-notifications branch 2 times, most recently from 90743cc to 2447461 Compare November 23, 2021 11:33
Comment on lines 208 to 209
BitbucketBuildStatuses buildStatuses = bitbucket.getBuildStatus(hash);
for (BitbucketBuildStatus bs : buildStatuses.getValues()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like this will blow up if getBuildStatus returns null.

@@ -157,7 +161,7 @@ private static void createStatus(@NonNull Run<?, ?> build, @NonNull TaskListener
statusDescription = StringUtils.defaultIfBlank(buildDescription, "The build is in progress...");
state = INPROGRESS_STATE;
}
status = new BitbucketBuildStatus(hash, statusDescription, state, url, key, name);
status = new BitbucketBuildStatus(hash, statusDescription, state, url, DigestUtils.md5Hex(key), name);
Copy link
Contributor

Choose a reason for hiding this comment

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

The added md5Hex call looked surprising but I now see you just moved it from the BitbucketBuildStatus constructor.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

looks like it was added to avoid issues with longer names #15

Comment on lines 652 to 666
@Override
public BitbucketBuildStatuses getBuildStatus(@NonNull String hash) throws IOException, InterruptedException {
return null;
}

Copy link
Contributor

Choose a reason for hiding this comment

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

And here it does return null, causing an exception in the caller. This should preferably be implemented, or at least the caller should check for null.

@@ -199,6 +204,15 @@ private static void sendNotifications(BitbucketSCMSource source, Run<?, ?> build
listener.getLogger().println("[Bitbucket] Notifying commit build result");
key = getBuildKey(build, r.getHead().getName(), shareBuildKeyBetweenBranchAndPR);
bitbucket = source.buildBitbucketClient();
if (sourceContext.doNotOverridePrBuildStatuses()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this have a special case for reporting the status of a pull request build?

Like, there is a pull request and it's first built once and the build status goes to Bitbucket all right. Then a user of Jenkins replays the build — there is no new commit. When the second build finishes, does the plugin decide not to report the status to Bitbucket because that commit already has one build status from a pull request — even though it's from the same pull request? It seems to me that the previous build status should be overwritten in that case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

for this case it shouldn't be a problem as notification for PRs being processed in the previous if statement, this is for "branches" only, you could check line 198

Comment on lines 6 to 8
<f:entry title="${%Do not override PR build statuses}" field="doNotOverridePrBuildStatuses">
<f:checkbox/>
</f:entry>
Copy link
Contributor

Choose a reason for hiding this comment

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

I would like a longer help text that describes what this setting does and why one would want to use it. Yes the information is in #324, but it's nicer to have it in Jenkins as well.

Copy link
Contributor

Choose a reason for hiding this comment

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

I meant, in src/main/resources/com/cloudbees/jenkins/plugins/bitbucket/BitbucketBuildStatusNotificationsTrait/help-doNotOverridePrBuildStatuses.html.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks, added

@KalleOlaviNiemitalo
Copy link
Contributor

Overall though, I feel the better fix would be to (1) abort the branch build as soon as Jenkins finds that there is a PR from that branch as well and (2) delete the INPROGRESS build status from Bitbucket when the build is aborted that way.

@sams-gleb
Copy link
Contributor Author

Overall though, I feel the better fix would be to (1) abort the branch build as soon as Jenkins finds that there is a PR from that branch as well and (2) delete the INPROGRESS build status from Bitbucket when the build is aborted that way.

Thanks for the review! Makes sense, I will look when I have time and mb will close this PR

@sams-gleb
Copy link
Contributor Author

Overall though, I feel the better fix would be to (1) abort the branch build as soon as Jenkins finds that there is a PR from that branch as well and (2) delete the INPROGRESS build status from Bitbucket when the build is aborted that way.

I took another quick look.. The main use case here is when we create a PR and still having a running branch pipeline which could overwrite PR status thus non-tested changes could be merged. Branches and PRs do share key so it might be not so simple to delete only in progress branch status, in many cases it might be already in progress status of PR

@sams-gleb sams-gleb force-pushed the feature/324-pr-notifications branch 2 times, most recently from dbbce48 to d2999e0 Compare November 30, 2021 06:00
@alexanderrtaylor
Copy link
Contributor

Those failing builds are not legit. It appears that the filename has gotten too long due to the length of the git commit hash when checking out inside of windows.

That being said, I am not sure this feature is all that useful @sams-gleb because what about things like main/versioned branches that you do want to know build status on?

To me instead of a checkbox that ignores anything but PR build status, I think it should be a regex which would let you ignore status notifications from anything not-desired. To me that is a more useful feature and also you will most likely have to add a test before this gets approved and merged in. Because this is something super useful to me I am going to try and help make some code changes to see if I can get it working

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants