how to reuse a single Bamboo build plan between multiple software projects?

[Evgeny Prigorodov]

We have about of 150 Python projects, each one with its own BitBucket repository and independent development schedule (consider components or micro-services).

We have set up a sample plan that builds a Python release package (e.g. `python setup.py bdist_wheel`) and then uploads it to the local PyPI repository. This plan needs to be reused for all 150 projects, the only step that differs is checkout.

One workable solution found so far is to keep sample build plan as a template, clone it for each Python project and specify exact source repositories during the cloning (by modifying the checkout step).

The problem with this approach is that any time when a template plan will need to be modified, like adding syntax checking step or sending notifications or whatever, then that would require replacing dozens of "outdated" cloned plans.

This community forum has suggestions on using plan branches, but in our case all projects live in separate Git repositories.

What is the right Bamboo approach to reusing the same build plan between multiple project repositories?

[Victor Debone · Accepted solution]

Hello @Evgeny Prigorodov welcome to the Atlassian community! :)

From your description, I understand that you would like to have a way to reuse configuration from different plans and avoid the really big task of keeping 150 projects up-to-date through Bamboo UI.

If that is correct, I would suggest that you can use Bamboo's configuration as code, Bamboo Specs. With Bamboo Specs, you are able to keep your configurations updated with less effort than through the UI. Bamboo Specs comes in two flavours: Java and YAML. They have different use-cases and trade-offs.

If you as a team are comfortable with Java, you could have the exactly thing you are looking for; You would write Java Specs in a single repository, with all your plan configurations, and use it to control how each of your projects is run.

You would be able to reuse pieces of plan configuration as any other code reuse. You would also have a good head start with the "View plan as Java Specs" functionality, which gives you the configuration of your plans ready to be copied to a Java Specs project and be used.

The trade-offs would be that a single repository to control a large amount of plans would result in many devs working to define their plans, or some more centralised approach to have their plans altered, depending on how Bamboo is being used in your company.

You can check the Java Specs documentation here.

In other hand, the YAML Bamboo Specs is not exactly what you are suggesting, but can still be handy. If you are running mostly Python projects, I would assume that probably your team is more comfortable with writing YAML. With YAML Specs, each repository would contain their plan definitions and developers would be able to easily control their build plans.

You will probably run to some more limitations than, that I can see from what you've described are:

• You cannot configure the checkout repository on YAML Specs; Because
• You need to keep the YAML Specs on the same repository your code resides; Also
• Some configurations (for example, plugins) are not supported yet in YAML Specs;
• The migration path is not that clear, given the YAML Specs need to be written by hand, Bamboo doesn't support "View plan as YAML Specs".

Still, that would be miles away from configuring all these projects from the UI and you could keep files in sync across repositories with much more ease than having them synchronised within the UI. You can check the YAML Specs documentation here.

If you have doubts or give some feedback about Specs, please don't hesitate to contact us. You can send an email to vdebone@atlassian.com. 

Did it help?

[Evgeny Prigorodov]

Hello, @Victor Debone, thank you for the fast and informative reply. We have tested Bamboo Specs approach and your idea seems to be exactly what is needed.

With Java Specs one can easily define reusable parts of build plans. Java Specs code creates plans in the runtime, so one class can maintain any number of derived plans with custom repository tasks. Upon any changes Bamboo makes sure that existing plans are being matched by their key or `oid()` and then updated accordingly.

There is only one unclear part now. Tutorials mention two ways of publishing Specs: manual action from the developer's workstation and automatic via push into Bamboo Specs repository.

We have tried the manual way and it works fine. But it would be ideal if the Java Spec build and run was done by the Bamboo itself.

We have set up configuration for automatic scan of Bamboo Specs in the linked repository, as described in the second tutorial. Then the text says:

As soon as you push your code changes to Bitbucket Server, Bamboo will get notified about a new commit available.

Bamboo will checkout your project, compile it and execute Bamboo Specs in a sandbox environment.

That does not work, nothing happens after a push. What can be missing and where we can look for debugging info?

Thank you,
Evgeny

[Victor Debone]

Hello @Evgeny Prigorodov

This answer fell through the cracks and I didn't answer it. Did you have your problem solved?

[Evgeny Prigorodov]

Hello, @Victor Debone 

Sorry for the delay in communication, there was a summer leave and then we have lost and recovered access to the Bamboo server.

The situation is still the same: Java specs works when pushed manually from developer workstation, but automatic execution after repository change does not happen.

This is how the problem can be reproduced:

1. We have created a sample project as described in the tutorial.
2. Verified it with `mvn test`.
3. Successfully pushed specs manually via `mvn -Ppublish-specs`.
4. Deleted automatically configured build plan.
5. Created a linked BitBucket repository as described in another tutorial .
6. Changed Java source and pushed the change to BitBucket server, -- nothing happened in Bamboo.
7. Added `bamboo-specs/bamboo.yml` and pushed the change to BitBucket server, -- nothing happened in Bamboo.

Following the threads with similar problem (first, second), we have tried the following:

• Checked the first troubleshooting step at https://confluence.atlassian.com/bamboo0602/bamboo-specs-troubleshooting-938867465.html. All settings are fine.
• Added native git v2.1.4 to server capabilities.
• Added maven v3.0.5 to server capabilities.

• Enabled `DEBUG` log level for `com.atlassian.bamboo.configuration.external.RepositoryStoredSpecsServiceImpl` and checked `atlassian-bamboo.log` for `[RssDetectionServiceImpl]` entries, no events at all.

• Deleted and recreated the linked repository.
• Tried `wget --post-data="" --header="Content-Type: application/json" "https://bamboo.unfccc.int/rest/api/latest/repository/scan?repositoryId=*******"`, the server returns HTTP 404.

Server-side execution of Bamboo Specs is important for us and we are ready to continue investigation. Do you maybe have any advices?

Thank you,

Evgeny

[Evgeny Prigorodov]

Hi @debone

We have found the problem cause: application link from BitBucket to Bamboo was broken.

The BitBucket host has been recently moved into a new network location but retained an old HTTP proxy address in its configuration, which then became unreachable.

The application link from Bamboo to BitBucket was configured correctly and Bamboo could poll repository changes, so regular build plans worked fine.

But the application link from BitBucket to Bamboo was broken and BitBucket could not propagate branch change events.

Thas was fixed and now we see [BranchChangedEventListener] and [RepositoryStoredSpecsServiceImpl] in the Bamboo logs, it indeed tries to process bamboo-specs.

There are some other errors still, but now Bamboo gives a lot of diagnostics and we can move on. I will update on final result.

Thanks,
Evgeny

[Victor Debone]

Thanks for the thoughtful response!

In hindsight, would be there anything that Bamboo could do to help you to figure out this problem earlier? I'm asking on some insight of where you were looking for this information, what steps apart from the ones you've described, where did you find information about the old proxy (did you just open Bitbucket's configuration and found the wrong url, or there was previous hints of that?), if you have looked into the Applink in Bamboo's side. Consider also, if you have a suggestion, that this problem is asking for Bamboo to be aware of something that it is not aware, like identifying a problem that it doesn't know it's there.

[Evgeny Prigorodov]

Thank you for this pursuit to improve the product and its documentation.

It is a lot of questions so the answer will be long :)

1. "would be there anything that Bamboo could do to help you to figure out this problem earlier?"

Additional line in the Bamboo Specs troubleshooting guide would be the most helpful.

There is already a step for checking Application Links in Bamboo, the missing part looks like the following:

1. Go to [gear icon] > Application links
2. Check that link to Bitbucket server exists and has green "Connected" status.
2. In the link to Bitbucket server, access the Actions menu on the right side and select "Go to remote".
3. Check that reverse link from Bitbucket to Bamboo also exists and has green "Connected" status.

It would be also good if the troubleshooting page contained some general debugging hints, e.g. how to identify the Bamboo version and host name, where are its config and logs stored and so on.

2. "where you were looking for this information, what steps apart from the ones you've described"

The first step was to find the logs, `Bamboo_home/logs/atlassian-bamboo.log`. There was no traces of errors or anything else happening after the push.

I followed through the troubleshooting guide and found nothing wrong, the Applink on the Bamboo side was always green.

Googling lead me to the very this Atlassian Community support forum. One thread mentioned `[BranchChangedEventListener]` log event which indicates the start of RSS execution.

This event was also not presented in our logs and that hinted to check the Bitbucket connection again. While examining it, I clicked on "Go to remote" and found the broken reverse Applink.

Before this lucky click there was also a number of failed hypotheses and trials, like creating and triggering a regular build plan that checks out the RSS repository, or playing with the YAML specs.

3. "where did you find information about the old proxy (did you just open Bitbucket's configuration and found the wrong url, or there was previous hints of that?), if you have looked into the Applink in Bamboo's side"

The Bitbucket Applink displayed an error message with `java.net.SocketTimeoutException`, but there was no related stack trace in the logs.

Found the failing connection itself, by running `watch lsof -a -itcp -p <Bitbucket_PID1>,<Bitbucket_PID2>` on the server console.

The IP address belonged to the network in which the Bamboo host was located previously, it was the address of HTTP proxy.

Grepping for the proxy host name in the Bitbucket install directory, found a result of past administration actions in the `bin/_start_webapp.sh`:

JVM_SUPPORT_RECOMMENDED_ARGS="-Dhttp.proxyHost=<proxy host name> -Dhttps.proxyHost=<proxy host name> ..."

Removed the wrong proxy setting variables and restarted the Bitbucket service. Then edited and re-established the application link, which became green.

Pushed another test change into RSS project, immediately observed new log events and received an email with specs execution log.

4. "Consider also, if you have a suggestion, that this problem is asking for Bamboo to be aware of something that it is not aware, like identifying a problem that it doesn't know it's there."

The Bamboo Specs tab on the linked repository page leaves an impression that it can execute specs from any remote repository, whereas the feature apparently works only with configured Bitbucket applink. A small text warning would be good there.

The Applink page would be more informative if it displayed status of reverse link and returned more detailed error messages (like unreachable IP address in `java.net.SocketTimeoutException` in our case).

Also the Bamboo specs execution resembles a special build plan (checkout, then maven -Ppublish-specs). In that sense it would be easier to debug (or even tune) if it behaved just like other build plans, e.g. was visible and configurable via UI, could be triggered by other means than Bitbucket pushing event, had similar build history and so on.

Thank you for asking.