I found a work-around for this.

take the example below

build plan has 4 different repos / plans

1. Database
2. Model
3. View
4. Final Application

Each build plan is dependent on the previous one.
Each build plan is linked to one repo

Apart from the final application, That has a default repo of the application
but also has registered the other repos.

Now when I look at the report for the final application. I get all the related builds and commits up the tree to what consistututed the makeup of that final application.

Hi Guys, Just thought I would add some more details. Following a delivery pipeline approach, any change to the application be it in the db, model layer, ui, webservice then we should be able to see any change downstream that caused the build and deployment.

Now in a lot of cases , each sub module may be in different repo. If I change the DB code and this kicks off child builds to the model layer, to the UI and then the final app. I should be able to see what changes contributed to the new version of the application.

If we are not able to see the individual commits, we should be able to see all the jira issues what have contributed to the actual build.

We are basically talking about a value stream map to trace from commit to deployment, and see upstream and downstream changes. You can see something similar here
http://www.go.cd/documentation/user/current/navigation/value_stream_map.html

Hope this helps.

Regards

Orlando Kelly

The main use case is a pipeline of plans with different repos with the final plan building/testing the master/full application.
e.g. API -> Front-end -> Full app

When reviewing the release of the full application, it would be nice to see all the JIRA tickets associated in building it.

I've re-opened this issue but changed it to require cascading the JIRA issue to child builds and not the commits.

This might be difficult and intentional as the child plan does not necessarily use the same repository. I'm going to close this issue as we are unlikely to implement it even as a flag and we can re-open it if there are more requests for it.

Since the parent and child plans are for the same repo, is there a reason not to use stages in the same plan?

Regards,
Josh

Hey there xtjhin,
Ideally the use case will be any repo or jira issue that provides data to a parent issue also provide that data to a child issue. The specific use case I raised this feature request of behalf of has both parent and child using the same repo.

Thanks!

Turner

Hey Bernard,

Is the use case using the same repository for parent and child plan?

Kind regards,
Joshua Tjhin
Bamboo Product Manager