Baseline Promotion in CC-UCM Plugin
9 views
Skip to first unread message
Chris Shannon
Jul 22, 2016, 2:06:30 PM7/22/16
to Jenkins Users
This is sort of specific to the ClearCase UCM Plugin, but may apply outside of it as well...
As our Jenkins jobs are expanding, we're breaking some large jobs into smaller pieces. As such, a generic example is:
SCM Job (listens for new INITIAL baselines via the CC-UCM plugin)
Build Job(s)
Test Job(s)
Because I'm dealing with snapshot views in ClearCase, I set these jobs up to all run on the same node and pass the path to the ClearCase view to each job. Because everything is running on the same node, I run into a whole host of other problems if I trigger the downstream builds in build steps (e.g. my node would need multiple executors) so they are post-build triggers.
The default behavior of the CC-UCM plugin is to promote my baseline to BUILT as soon as that first SCM Job is complete. Well, that job only creates the view and does actually perform the build. In reality, we actually have several different build jobs, many using different compilers, which make up a "good build".
So, really I want to promote the baseline to BUILT after the last of my build jobs, and promote it again to TESTED after the last of my test jobs. I don't see any way for the plugin to look for INITIAL baselines and *not* promote the baseline. I could pass the baseline name around and use raw cleartool commands to handle my own promotion logic downstream, but I just want to make sure I'm not missing something basic.
If this is too specific to ClearCase, am I doing something wrong at a high level? I like the additional visibility we get when I break up my jobs into smaller pieces, but my "BUILT" decision is now in a different job from my SCM Job. How do I propagate the build results without holding two executors?
As our Jenkins jobs are expanding, we're breaking some large jobs into smaller pieces. As such, a generic example is:
SCM Job (listens for new INITIAL baselines via the CC-UCM plugin)
Build Job(s)
Test Job(s)
Because I'm dealing with snapshot views in ClearCase, I set these jobs up to all run on the same node and pass the path to the ClearCase view to each job. Because everything is running on the same node, I run into a whole host of other problems if I trigger the downstream builds in build steps (e.g. my node would need multiple executors) so they are post-build triggers.
The default behavior of the CC-UCM plugin is to promote my baseline to BUILT as soon as that first SCM Job is complete. Well, that job only creates the view and does actually perform the build. In reality, we actually have several different build jobs, many using different compilers, which make up a "good build".
So, really I want to promote the baseline to BUILT after the last of my build jobs, and promote it again to TESTED after the last of my test jobs. I don't see any way for the plugin to look for INITIAL baselines and *not* promote the baseline. I could pass the baseline name around and use raw cleartool commands to handle my own promotion logic downstream, but I just want to make sure I'm not missing something basic.
If this is too specific to ClearCase, am I doing something wrong at a high level? I like the additional visibility we get when I break up my jobs into smaller pieces, but my "BUILT" decision is now in a different job from my SCM Job. How do I propagate the build results without holding two executors?
Reply all
Reply to author
Forward
0 new messages