I read here (short-lived branches) that a known limitation is:
- Analysis of a short-lived branch based on another short-lived branch is not supported.
Does this mean that resolutions for issues marked on a short-lived branch will not propagate to the PR analysis?
This is correct.
BTW, our assumption is that if you’re using PRs, you’re going to prefer analyzing them to their short-lived branches of origin, and in fact see no need to analyze the SLBs. At least, we don’t.
I’m curious to understand why you would analyze both forms of the same thing. Or is this post just an effort to fully comprehend how the feature works?
PRs get merged with target prior to build in our pipelines. You can push up an SLB without a PR to get an analysis early. Additionally, an automatic merge has occasionally highlighted code smells (like complexity or others).
So we have to disable the quality gate on one or the other if there are issues (since we can’t yet change the gate for SLBs)
We are using the quality gate as a merge check (on source and source merged with target) because otherwise the analysis goes unobserved.
For a little better context: we are using bibucket server and so do not have dynamic PR gates - instead relying on a static analysis result