How to not run dependent plan if changeset does not match 'include file' in repository settings

Question

Hi,

We have a repository which contains partially dependent projects. Lets say ProjectBase, ProjectA and ProjectB, ProjectA references ProjectBase and ProjectB also references ProjectBase, but ProjectA and ProjectB are otherwise independent. We need to compile all projects together due to these references, but we need to test them separately. This means, when changes occur on ProjectA, we do not need and do not want to run test for ProjectB, we need to run tests for ProjectA only.

We come up with the solution using dependent Bamboo plans. First plan checks out code from repository and compiles all projects with their test projects and publishes them in an artifact. Then we have plans that run tests for specific projects, one plan for ProjectA tests and one plan for ProjectB tests. These plans consume that artifact and use the compilation output of the first plan. They do not need to checkout the repository again, everything is contained in the artifact. The repository is rather large and we want to check it out as few as possible. We set same repository for the test plan to ensure that it will test same changesets as the compilation plan.

How can we run the test plans according to a changeset that runs a compilation plan? We observed that when the changeset is in ProjectA, plan for ProjectB correctly has no changeset listed in 'Commits' tab, but since it is a child plan of the compilation plan, it still got triggered and run jobs for that project.

Note: blocking test plans/waiting for the compilation plan to complete works as expected. For simplicity I describe the problem using only three projects, but we have about 15 projects in that repository, so it is crucial for us to run only tests that matter at the moment of a commit. Obviously, when the changeset is in ProjectBase, it triggers all test plans, there is no way around it.

Note 2: Sorry for possible duplicity, I asked about hour before but I cannot find the question in question list any more.

Daniel Santos_157bm4 · Answer

Hi @Pavel Matyska

You are always welcome!

I really think the best approach is to have the projects self-contained. I didn't insist on this idea because it would probably require a repository refactory (to reduce disk usage).

Regarding your idea for an improvement request, I just opened one:

* [BAM-20582] Allow conditional triggering of child plans

Thank you for sharing your feedback about the feature request.

Have a good one!

Pavel Matyska · Answer

Hi Daniel,

Thank you for your response. We also thought about having a plan per project which would have compilation stage and test stage, although this configuration uses more disk space. It would also enable us to see results of last test run for each project. In the workaround solution when some test jobs would still be executed but skip running the tests, it would result in "passed" job state which would hide those last results.

We will try your suggested best option and see if it makes us happy.

Just a thought about triggers for one of your next version of bamboo. Would it be possible to make trigger of dependent plans appear in triggers tab of the plan (along with repository polling, schedule, ...) and make some "binary operators" on them, so a user can say: I want to run this plan when "(triggerA AND triggerB) OR triggerC" is triggered. It could open some new path of plan chaining. Also, it will enable a user to see all of the triggers at one place.

Anyway, thank you for your time and responses.

Pavel

Daniel Santos_157bm4 · Answer

Hi @Pavel Matyska

I think the sequence is correct. In my opinion (If I understood you correctly) this scenario is caused by:

* Your subsequent projects are not self-contained due to the disk space restriction, requiring that ProjectBase is run every time to compile their code.
* Bamboo has no feature for conditionally running dependent plans

What I see that could work (as a workaround):

* Moving your subsequent plans to the main one. All of them as parallel jobs in the same stage
* Configure your tests to be parallel jobs in the last stage.
* Each job using a script task to call the tests.
This script will check variables to know if they should run or not the tests.
The job would run but would save a lot of time when there is no test to be run.
⚠️Keep in mind that parallel jobs require multiple agents available.

To discover which repository triggered the build you use a script like the one shared here: Determine which Repo triggered a build

I know this is not an elegant solution. I think the best option would be having each client compiling and testing its own code. You shouldn't need to compile ProjectBase if the changes are only happening on dependent plans.

There is a feature request that would be helpful in this case:

* [BAM-11257] Conditional build step depending on value (or existence) of variable

I tried a solution with the plugin mentioned in this thread (Solved: How we can configure job with conditional tasks... ) but it does not accept injected variables.