-
Suggestion
-
Resolution: Fixed
-
None
-
None
We use dependencies as a work-around for not having multiple build triggers.
(1)
In this case there is no need for a "builder" script. Since Bamboo requires one, we run a bogus shell command like 'echo'. That is a minor problem but it's an annoyance. If Bamboo will not support multiple build triggers, we need the builder to be optional.
(2)
There is no need to pull source. Bamboo requires source repository info to be provided. So we pull in a small part of our subversion repo for no reason other than to make Bamboo happy.
There should be separate tabs for "Source Repository" and "Triggers." I understand they are related, but triggers should not require a source repository depending on the type of trigger desired.
- is related to
-
- Closed
[BAM-8031] Changes needed for workaround for lack of multiple triggers
Terris Linenbach
added a comment - Plan reuse is a powerful and needed concept in any workflow product, whether it knows it's a workflow product or not. We don't want to have a bunch of plans that are mostly alike just because Bamboo doesn't have a multi-trigger feature.
Terris Linenbach
added a comment - Plan reuse is a powerful and needed concept in any workflow product, whether it knows it's a workflow product or not. We don't want to have a bunch of plans that are mostly alike just because Bamboo doesn't have a multi-trigger feature. Terris Linenbach
added a comment - For us, a build artifact is the entire source tree because our code is Perl - nothing is actually built and our builds are really syntax checks (this is yet another reason why Perl should not be used). I'm not sure how well treating an entire directory under build-dir as a build artifact would work, but it stands to reason the new artifact sharing feature in 3.0 would solve #2. If you look at what we're trying to accomplish, it's really about getting Bamboo to do workflow-type stuff like "run this plan at 12 AM" where such an instruction has nothing to do with building, testing, or source code.
Terris Linenbach
added a comment - For us, a build artifact is the entire source tree because our code is Perl - nothing is actually built and our builds are really syntax checks (this is yet another reason why Perl should not be used). I'm not sure how well treating an entire directory under build-dir as a build artifact would work, but it stands to reason the new artifact sharing feature in 3.0 would solve #2. If you look at what we're trying to accomplish, it's really about getting Bamboo to do workflow-type stuff like "run this plan at 12 AM" where such an instruction has nothing to do with building, testing, or source code. 
Rene Medellin [Atlassian]
added a comment - Our unit tests take so long that we separate builds from tests in order to publish build artifacts asap
As a temporary workaround, does your build tool (ant, maven, nant) support passing a property to skipTests?
You could setup your artifact-publishing as a separate job (maybe even in a separate plan) that would skip running the tests if you don't care about linking the passing of the tests to the generation of the artifacts
Also, what unit test framework are you running? You could also create a stage with a single job and test in it that could check the state of your database and fail the test if it wasn't available. Subsequent tests would then not run if the DB was down.
Rene Medellin [Atlassian]
added a comment - Our unit tests take so long that we separate builds from tests in order to publish build artifacts asap
As a temporary workaround, does your build tool (ant, maven, nant) support passing a property to skipTests?
You could setup your artifact-publishing as a separate job (maybe even in a separate plan) that would skip running the tests if you don't care about linking the passing of the tests to the generation of the artifacts
Also, what unit test framework are you running? You could also create a stage with a single job and test in it that could check the state of your database and fail the test if it wasn't available. Subsequent tests would then not run if the DB was down.
Terris Linenbach
added a comment - Another Trigger we'd like to have is to run a plan if another plan is in the complete-and-failed state so we can re-run our tests which frequently die because the database is down at 2 AM and nobody notices.
Terris Linenbach
added a comment - Another Trigger we'd like to have is to run a plan if another plan is in the complete-and-failed state so we can re-run our tests which frequently die because the database is down at 2 AM and nobody notices. Terris Linenbach
added a comment - Better said.. we have a build plan that is triggered via cron and runs the unit tests as a child plan.
Terris Linenbach
added a comment - Better said.. we have a build plan that is triggered via cron and runs the unit tests as a child plan. Terris Linenbach
added a comment - Our unit tests take so long that we separate builds from tests in order to publish build artifacts asap. First, we run the unit tests after the "build" plan. That's one dependency. Secondly, we run the unit tests at midnight every day regardless of whether the code changed to make sure our test databases are running. Therefore, the second dependency is cron.
Terris Linenbach
added a comment - Our unit tests take so long that we separate builds from tests in order to publish build artifacts asap. First, we run the unit tests after the "build" plan. That's one dependency. Secondly, we run the unit tests at midnight every day regardless of whether the code changed to make sure our test databases are running. Therefore, the second dependency is cron. 
Multiple Build Triggers feature is part of upcoming 4.3 release.