Builds depending on status of other builds through Recipe instructions

[m.jason.miller@…]

I have created a patch to the queuing system which allows an additional XML recipe command to instruct the bitten-master queuing system to iterate through the dependency information contained within the new recipe command, and determine whether or not to supply bitten-slave the build go-ahead.

XML recipe example:

<build xmlns:sh="http://bitten.edgewall.org/tools/sh"
           onerror="continue"
           requires="recipe_name_01(target_name-01,target_name-02) recipe_name_02(target_name-01,target_name-119)">

  <step id ... </step>

</build>

(xmlns and onerror are not required. I include them here to make the example easier to read. As we are all used to seeing those in our build headers)

recipe_name_## = The unique recipe name identifier. Not the label or some such.
target_name-## = The target platform name. Not the label or some such.

To specify two build recipes as dependencies, simply add another using a SPACE. I use the space as the delimiter for build recipes.
Encapsulate all your desired targets within a single recipe with parentheses. To specify multiple targets within a recipe, use a COMMA only. No spaces here.

The allowable characters you see in the example are about it I believe. I imagine anything Trac allows within those fields will work. As I am only searching for spaces, commas and parentheses.

[m.jason.miller@…]

The queue.py patch file

[anonymous]

Problem!

I was only testing using one revision... so my method of grabing the status of a build is incorrect (big time)

Fixing now... I should have a patch up soon.

[m.jason.miller@…]

Allows for latest revision on targets to be used. Fixes older patch.

[Bernd Keimel <unowned60@…>]

MASTER,

my name is bernard ( buildslave) Properties by MASTER!! MASTER ask for more order, or instruction!!

buldslave

[Jason Miller <m.jason.miller@…>]

Replying to Bernd Keimel <unowned60@…>:

MASTER,

my name is bernard ( buildslave) Properties by MASTER!! MASTER ask for more order, or instruction!!

buldslave

By order if you mean dependency order... I guess I could explain a little more. The dependencies will be checked from left to right in the requires= XML command. I suppose ultimately it does not matter however, because if just one dependency is found not to be met, I return False (do not allow) to the build-master queuing system. You can witness the dependency failures (and successes) while tailing the trac.log in debug mode: tail -f trac.log | grep 'Trac\[queue\]'

More instructions? Ok:

Say you have one recipe named Frameworkdueto Checkin Devel Branch?:

<build xmlns:sh="http://bitten.edgewall.org/tools/sh">

  <step id="checkout_framework_devel_branch" ... </step>
  <step id="build_framework_devel_branch" ... </step>
  <step id="merge_framework_devel_with_framework_stable" ... </step>

</build>

And now you have a single Application which depends on the Framework being stable:

<build xmlns:sh="http://bitten.edgewall.org/tools/sh"
       requires="FrameworkduetoCheckinDevelBranch(intel-arch,gnu-arch)">

  <step id="checkout_framework_stable_branch" ... </step>
  <step id="checkout_application_devel_branch" ... </step>
  <step id="build_framework_stable_branch" ... </step>
  <step id="build_application_devel_branch" ... </step>
  <step id="merge_application_devel_with_application_stable" ... </step>

</build>

The above Application recipe will only proceed if the latest revision of Framework Stable with both an Intel target and GNU target have been found with a status of: Success

Using this method here and there through out my build recipes, I am able to remove and no longer maintain several 'growing' complex scripts. (I am _even_ toying with the idea of cross Trac environment build statuses... Mawhahaha... Because my framework will in the future require other stable frameworks controlled via a different Trac project)

I now only have to run bitten-slave (not some crazy pre-initialization script to determine the above). I also no longer need post-commit hooks to fire off a stable build and halt any and all others that may require this branch due to a checking while my framework is being built/tested... in this _very_ specific order I need in _my_ environment and _only_ with this recipe. All of this control, right within the simple build requires= recipe. So simple, my team mates can now understand each other's needs, and code it up themselves. No need anymore for anyone to hunt down someone else's crazy how-does-this-work-or-how-did-this-ever-work script.

That last paragraph is truly the most important part. Every one's requirements of Bitten and Trac are very different from one another. I am extremely thankful to the Trac and Bitten team. They have designed a product capable of being this diverse.

Got a little carried away there :)

[Jason Miller <m.jason.miller@…>]

Fixes first target of same dependency to cause a True situation, when in fact, there are multiple dependencies to satisfy. Also corrects some grammer.

[Jason Miller <m.jason.miller@…>]

Fixing a very rare possibility... If one has two target dependencies within the same recipe, it will never get created (which is what SHOULD happen any). Sorry for the double patch and not checking it more thoroughly.

[Jason Miller <m.jason.miller@…>]

Sorting was being done incorrectly - fixed. Cleaned up debugging output.

[Jason Miller <m.jason.miller@…>]

I added the ability to match the same pattern in another recipe, as the pattern in the calling recipe. That is, if you have multiple recipes with the same target patterns, you can now inform the recipe to depend on another recipe with the same target being successful first.

<build xmlns:sh="http://bitten.edgewall.org/tools/sh"
       requires="recipe_name1($PLATFORM) recipe_name2(gnu-target,intel-target)">
...
...
</build>

Note: You can continue to specify other individual targets in addition to the new $PLATFORM requirement as demonstrated above.