TW-79075 Publish commit status selectively for feature branches builds#56
TW-79075 Publish commit status selectively for feature branches builds#56idlsoft wants to merge 1 commit intoJetBrains:masterfrom
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.
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.
In fact it would be better to rely on BuildTypeEx::getLogicalBranchNames instead
There was a problem hiding this comment.
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.
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.
Agree, this is more of a failsafe if the code doesn't work for some reason.
2 participants
For feature branch builds only publish status for participating commits, commits coming from default branches will be skipped