-
Notifications
You must be signed in to change notification settings - Fork 89
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
TW-79075 Publish commit status selectively for feature branches builds #56
base: master
Are you sure you want to change the base?
Conversation
…ing commits, commits coming from default branches will be skipped
if (buildBranch != null && !buildBranch.isDefaultBranch()) { | ||
Set<String> selectedBranchNames = new HashSet<>(); | ||
selectedBranchNames.add(buildBranch.getName()); | ||
selectedBranchNames.add("refs/heads/" + buildBranch.getName()); // git prepends this to the branch name |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems this relies on a (false) assumption that branch specification of the respective VCS root is always +:refs/heads/*
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In fact it would be better to rely on BuildTypeEx::getLogicalBranchNames instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hated that bit too :)
Ideally the trigger would propagate if the branch is matching or a default
); | ||
revisions = revisionsForBranch; | ||
} else { | ||
LOG.warn("Attempted selective publishing, but did not find revisions for buildBranch=" + buildBranch + " among " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Within this new functionality scope, I don't think it's correct to fall back to publishing statuses to all revisions if we cannot find a relevant subset. When there is a build chain, it could be the case that some builds in it are fully falling back to default VCS branches wile other builds running on non-default VCS branches, despite all of them marked by a non-default logical branch. It seems we should only publish statuses for the latter kind of builds in such a case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, this is more of a failsafe if the code doesn't work for some reason.
For feature branch builds only publish status for participating commits, commits coming from default branches will be skipped