Optimal route to file-triggered build

[Oliver Oliver]

We've finished our Bamboo evaluation and are beginning the (slow) process of migrating a 10-year in-production project into the care of Bamboo.

Our version numbering is currently manual, someone edits proj/VersionNo.h and checks it in. We use <product version>.<release number>.<patch number>.<build no> where build no is actually a 0-255 value within the first three quads, e.g. 1.34.0.0 is the first build of product version 1, release 34, patch 0.

I have a nightly all-configurations build that I want to trigger automatically any time proj/VersionNo.h is checked in, and then when that is working, I want to add a plan to run a script that updates VersionNo.h...

It seems like I need to create a new plan which monitors proj/VersionNo.h for checkins, which is a parent project for the daily build.

And then create a parent project to that which runs the upversion script and checks in the result, and allows it to trigger.

But somehow this doesn't feel right or optimal to me. Would it be better to have the repository telling Bamboo when the file changes and triggering the specific plan?

[Dennis Ryan]

your repository trigger, if you use one, can look for this partiular file, and trigger the appropriate build. I use a similar strategy to avoid building when only project files (intellij,eclipse) files are checked in.

[PiotrA]

Hello Oliver,

To set up a "Nightly all-configurations build" I'd create a Bamboo Plan that would use *scheduled* *poll* strategy (once per day, at 3am for example). In the plan advanced repository options I'd set the file pattern filter to only trigger the build when it detect a file .*proj/VersionNo.h.* was changed (or similar regexp, you got the idea).

What other plans do you need to set up?

regards,

[Oliver Oliver]

Note: I *think* I can make a single-file based filter by specifying the individual file-path as the subversion repository elsewhere, but (a) I have to start repeating branch names in input fields, (b) I can't have both a scheduled and a repository-scan trigger...