Link build configs when determining build order
I have a couple of build configurations for one project that look like this:
Build Config 1:
- build
- run tests
- package artifact
Build Config 2 (takes artifact from 1)
- create octopus deploy release
I'm only running with a single build agent. My builds can sometimes take a while and certain projects have a higher build priority. The issue I'm experiencing is that in between running Build Config 1 and Build Config 2, the agent will jump to another project, despite Build Config 2 having a higher priority. I'm guessing this is because the build order is determined when the build task is created.
Is there a way to link the two build configs to ensure Build Config 2 will be run immediately after Build Config 1? My quick and dirty approach would be to have a timeout between the items in the build queue which would allow the second item to be correctly ordered based on the Build Priority, but there might be a better way to accomplish this.
Please sign in to leave a comment.
Hello Andrew,
I don't think there is a way to have two build configurations run immediately after each other. Build configs are indented to run at different times on different machines, in general, plan accordingly. There are several solution to the problem depending on what you want:
If the "create octopus deploy release" MUST run immediately after the other configuration then I think the easiest solution is to add the steps to the first build configuration and/or create a Metarunner (Love this feature of TeamCity) of the steps for reuse purposes.
If the "create octopus deploy release" needs to run ASAP then you can add it to the top of build queue , via say the REST API https://confluence.jetbrains.com/display/TCD18/REST+API#RESTAPI-TriggeringaBuild (Also exists in TeamCity 10 and 2017) Note that if one adds lot of builds to the front of the queue, then TeamCity's "avoid starving build configurations" build queue rules will be up set. Especially if one starts have multiple builds that chaining and adding to the front of the queue. Note that build second build might still not be run next if other things (builds, people, etc.) add to the front of the queue after the first build adds the second. Multi-threading perverse issues aside adding the second build to the frond of the queue will get you close to what you want.
If the "create octopus deploy release" needs to run soon, then I think you have the best solution with maybe needing a slightly higher priority, or adding another build agent if the you queue is too full most of the time. Note the the build queue priority class are not the only factor in build queue priority, there are many others.
Thanks Chris.
I think the idea with having two different build configurations was that I could create a new release for Octopus independent of build/test/package process. This is useful when say, Octopus configuration has changed and a new release needs to be created. If I have two separate build configurations I can just run the (quick) "Create octopus deploy release" without having to create a new build (slow).
I think that your second option is what I'm doing now (not with the REST API but with the build priority instead). The "create octopus release" build task is put at the top of the queue, but I think it's only put there after another build task is started, as your second to last paragraph noted. If there was a way to set a timeout before an agent started building the next item in the queue, I think that would resolve it for me (running the second build config only takes a few seconds) but I can understand this is not exactly an elegant solution.
Sounds like I'm not going to be able to achieve what I need unfortunately. No big deal. Perhaps if my builds took significantly longer then it would become a requirement, but at this stage it's just a nice-to-have.
Hi Andrew, and thanks Chris for the help.
To be accurate, Build priorities cannot guarantee that a build will always run before anything else, as an algorithm is in place to avoid builds staying in the queue forever due to starvation. Build priorities affect the order when builds are assigned into the queue, and agents will pick up builds from the queue as required.
Whlie there isn't a direct way to guarantee that the build will run instantly after the other, you could set some builds to only run on some agents, or not to run on some via agent requirements: https://confluence.jetbrains.com/display/TCD18/Assigning+Build+Configurations+to+Specific+Build+Agents
This might help you manage a bit further what gets run where.