I have configured a plan bamboo to build a project. This plan first checkout the latest code from SVN and executes a command to build the project. Building of this project takes 4hrs-5hrs. I want my plan to run continuously i.e if the plan creates one build then immediately bamboo should start another build. I want the event to start building a project should completion of previous build not commiting something in to svn. Is there any way I can achieve this?
You can create a scheduled trigger with a cron expression causing your plan to build every X minutes. X should then be <= the estimated build time. Disadvantage may be that it can cause to have multiple builds in the build queue after a while.
To do this I would do the following.
In the plan settings you can set the maximum number of builds to be 1 at an time.
Then configure the queue to be maximum of 1.
This way only a single build will build with only a single job in the queue.
Then you can either "set a scheduled trigger with a cron expression causing your plan to build every X minutes"
or make a final step do a commit to the repo when if you have a change driven trigger it would immediately run another job as it would detect a change.
Related
We have a test that takes several hours to run and that we'd like to run on our codebase as often as possible in GitLab CI. The idea is for it to validate as many commits as possible by merging them from dev into main but we know it's too slow to run on every commit.
It could run on a schedule, e.g. 18:00 every evening, but then it would run unnecessarily if there have been no changes and it wouldn't run as often as it could, e.g. 2-3 times a day.
Limiting concurrent jobs as suggested here isn't enough because the jobs will pile up, one per commit, and there will never be time to run them all.
We'd like it to complete the test for one commit, and then restart on the latest commit available, skipping over any commits that came in earlier.
I've looked through the rules section of the docs but don't see any magic variables that would let me say "run this job if it's not already running". Perhaps some kind of semaphore as described here (requested but not implemented as far as I can see).
How can we tell GitLab CI to run this particular job only if it's not already running and skip the job otherwise?
I have a number of multi-part tests that require me to run a setup phase first, then wait about 30 minutes before I can run the verification phase. I'm limited to a single agent, so including the delay in the test itself is very undesirable as it ties up the CI/CD system.
What I would like to do is have the setup plan, when complete, cause the corresponding verification plan to be scheduled 30 minutes later.
I know you can have one plan trigger another plan, but that's not quite what I want as that will happen immediately after the first plan, which won't work.
What's the best way to do this with Bamboo or is it even possible?
Not possible. Unless you delay the job programatically from a script task which, as you mention, is not ideal for your use case.
I am using SQL Server 2014 and I have a SQL job (an SSIS package which contains 11 steps) which has been scheduled to run on a daily basis at a specific time.
I know one can schedule each step to attempt a retry whenever that step fails. However, is there a way to configure a retry for the whole SQL job whenever the job fails at any step during the process? That is, if say, the job fails at Step 8, the whole job is run again from Step 1.
The tidiest solution I can think of would be creating an error handling Step in your Job which will be executed when any other step fails (change the On Failure action of all other steps to jump to this one) and managing the job's schedule to trigger again on the following minute, after the job ends. This way you will see the execution history of the job at the agent.
You will have to keep in mind recurrent failures, I doubt you want the job to be repeating itself indefinitely.
To configure the job to trigger, you can add a Schedule that fires every minute and enable/disable it when necessary. The job won't fire if it's already running.
I'm using bamboo to automate performance tests that should be run every night. I implemented two tests: first that run big queries and second that checks performance results.
First test (running queries) should be executed and after two hours second one (checking performance results) should be run. Obviously I don't want compile these tests into one test that run queries, waits 2 hours and checks results.
My solution is to have two bamboo plans: first plan with running queries test scheduled for 1:00 AM and second plan with checking performance results test scheduled for 3:00 AM. That works.
Is it possible to execute those tests within one bamboo plan (for example by setting two stages (with one test each) and setting delay between stages execution)?
Edit:
I have working solution that doesn't block agent for delay time (two scheduled plans). It works. I'm just wondering if it's possible to achieve same effect within one plan - sounds like functionality that could be available in Bamboo.
If blocking the build agent for 2 hours is not an issue, you may add a script task at the end of the first stage, so that it waits for 2 hours until the next stage is started.
sleep 2h
You may also define your result plan as a child plan (in Dependencies tab) and then introduce a sleep time using script task at the end of the first plan.
This way, your first plan will finish executing after 2 hours followed by the child plan.
Update: If your plan A is connected to a repository and is triggered when there is a new commit, you may connect the same repository in plan B and introduce a quiet period that will wait for 2 hours before it executes. This way, your agent is not blocked for 2 hours.
Is there a plugin or can I somehow configure it, that a job (that is triggered by 3 other jobs) queues until a specified time and only then executes the whole queue?
Our case is this:
we have tests run for 3 branches
each of the 3 build jobs for those branches triggers the same smoke-test-job that runs immediately
each of the 3 build jobs for those branches triggers the same complete-test-job
points 1. and 2. work perfectly fine.
The complete-test-job should queue the tests all day long and just execute them in the evening or at night (starting from a defined time like 6 pm), so that the tests are run at night and during the day the job is silent.
It's no option to trigger the complete-test-job on a specified time with the newest version. we absolutely need the trigger of the upstream build-job (because of promotion plugin and we do not want to run already run versions again).
That seems a rather strange request. Why queue a build if you don't want it now... And if you want a build later, then you shouldn't be triggering it now.
You can use Jenkins Exclusion plugin. Have your test jobs use a certain resource. Make another job whose task is to "hold" the resource during the day. While the resource is in use, the test jobs won't run.
Problem with this: you are going to kill your executors by having queued non-executing jobs, and there won't be free executors for other jobs.
Haven't tried it myself, but this sounds like a solution to your problem.