requestTeamBuild ant task and team.scm.buildOnlyIfChanges
RTC 3.0.1.2
BF 7.1.2
Question - short: is there a property that can be set for the requestTeamBuild ant task to tell it that this is is a scheduled build, not a user requested one?
Background:
We have a pretty big system with 50+ components which each have their own RTC build definition (and all use the same BF project). The build for each component takes between 5 min and an hour and each component is owned by a different team, which is why we have the separate build defs and not 1 big one.
Historically (10+ years), the dependencies between components are kinda known (and a work in progress admittedly).
The BF job calls the JBE adaptor to load the workspace.
If I put the bd itself on a schedule and select "build only if there are changes accepted", it works.
Question - long:
I have created a RTC bd and BF job that will call the component builds in the right sequence via the ant task requestTeamBuild and start that via a RTC scheduled build. However (works as documented) it will always build every component - message "Yes: Always build a user initiated request." and ignore buildOnlyIfChanges.
I would really like to use the JBE functionality and all the cleanup it does to not build some components.
Is there a property I could set for requestTeamBuild so RTC thinks that this is a scheduled build and honors the buildOnlyIfChanges?
BF 7.1.2
Question - short: is there a property that can be set for the requestTeamBuild ant task to tell it that this is is a scheduled build, not a user requested one?
Background:
We have a pretty big system with 50+ components which each have their own RTC build definition (and all use the same BF project). The build for each component takes between 5 min and an hour and each component is owned by a different team, which is why we have the separate build defs and not 1 big one.
Historically (10+ years), the dependencies between components are kinda known (and a work in progress admittedly).
The BF job calls the JBE adaptor to load the workspace.
If I put the bd itself on a schedule and select "build only if there are changes accepted", it works.
Question - long:
I have created a RTC bd and BF job that will call the component builds in the right sequence via the ant task requestTeamBuild and start that via a RTC scheduled build. However (works as documented) it will always build every component - message "Yes: Always build a user initiated request." and ignore buildOnlyIfChanges.
I would really like to use the JBE functionality and all the cleanup it does to not build some components.
Is there a property I could set for requestTeamBuild so RTC thinks that this is a scheduled build and honors the buildOnlyIfChanges?
2 answers
Hi Martina,
What comes to my mind is that you can create different build definition for scheduled build and separate for requested one.
Let me know if it helps.
Best reagards,
Krzysztof Kazmierczyk.
What comes to my mind is that you can create different build definition for scheduled build and separate for requested one.
Let me know if it helps.
Best reagards,
Krzysztof Kazmierczyk.
Comments
hmm, I don't see how that will help unless I somehow manage to put together an ueber-POM or antfile so I have 1 build.
I want to have the flexibily of calling the existing build defs and doing that in sequence. Down the road the components may come from different RTC projects.
(we do incremental builds and keep the workspaces loaded, so for space reasons I have to call the build defs).
RTC is very particular (and I think unnecessarily limiting) about when it will do the buildOnlyIfChanges
What I ended up doing is writing an ueber-makefile generator that uses dependencies from a previous mvn dependency:list and also does a scm compare to check whether there are changes. I can run that with -j 3 and our 8h+ build is now in the 2 - 3h range, depending on how many changes there are.
having the dependencies and having make do the parallel optimization was they key point.
having the dependencies and having make do the parallel optimization was they key point.