Will this work in the below case:

    /-> p1 -- \
git            -> p3 -> p4
  \ \-> p2 -- /      /
   \----------------/

current pipeline is p3. p1-1 built off of g1, p2-1 built off of g1. p4-1 built off of g2.

@srinivasupadhya - what's the build cause for P3 here? Did you mean to say that current pipeline was p4? If current pipeline is p3, then the build-cause for p4 will not affect P3 in anyway!

@jyotisingh yes. it wont. but if im not wrong we will show the warning on p3 since material revisions for git will be g1 & g2.
also, p3 is current & build cause is p1-1 & p2-1.

if the current pipeline is p3, then g1 will be the only revision for git. P4 being a downstream, will not cause revisions to get added to the scm nodes, ie. git in this case. Thats how it has been all this while and I do not see any of that changed in this PR.
Is there some code in specific that you think could potentially cause issue? Can you point it out.

ok. i forgot we populate SCM data only for upstream pipelines. ignore 👍

ok. i forgot we populate SCM data only for upstream pipelines. ignore 👍

shocked :)

@maheshp: Adding a little screenshot to this might help everyone get an idea about how it looks.

Also, this is related to #1924. Commenting so that GitHub links the two together.

If the current pipeline is built from incompatible revisions a warning is shown and the SCM node lists all the revisions responsible for the build.

@FredrikWendt - thought you might be interested in this

YAY! \o/

I assume this only looks at SCM revisions, and not the case where two different run instances of any pipeline?

    /-> p1 -- \
p0            -> p3 -> p4
  \ \-> p2 -- /      /
   \----------------/

If p1 was run with p0:1 and p2 with p0:2, would p3 be red flagged?

@FredrikWendt

If p1 was run with p0:1 and p2 with p0:2, would p3 be red flagged?

Yes p3 would be red flagged if p3 is triggered with p1(p0:1) and p2(p0:2) assuming p0:1 and p0:2 SCM revisions differ

@FredrikWendt

I assume this only looks at SCM revisions, and not the case where two different run instances of any pipeline?

Adding some context about the implementation.

• The build cause for any pipeline run boils down to a set of SCM modifications(revisions), this can be represented as MaterialRevision(basically a Material with one or more modifications).
• While building a VSM for a pipeline we traverse through all the upstream pipelines and list all the MaterialRevisions responsible for the run. If the MaterialRevisions differ we flag the pipeline and list the MaterialRevisions as part of the SCM node.
• In case of manual trigger there could be instances where the MaterialRevisions differ.