Trigger consecutive builds within a single build chain

Hi,

First, if you don't want to rebuild with the changes from monday, and always want to deploy the version that was deployed to staging on monday, you should remove the snapshot dependency. A snapshot means that a build on the Tuesday one, should additionally trigger a build on the Monday one. While in your case it might make sense from an abstract point of view, as they do form a chain, we don't currently have delays between builds, so this tool can't do that. If you want that as a feature, you can create it in our tracker here: https://youtrack.jetbrains.com/issues/TW

This said, it might be relatively easy to accomplish that in a different way. First of all, if you always need to deploy the same version to both environments, it would make sense that the "build" itself is a separate build configuration. Then that build should post the output as an artifact (or multiple artifacts), and the deploy configurations set it up as an artifact dependency. Then the build only happens once (on monday, as a snapshot dependency of the staging deploy), and the deployment can easily reuse it without having to redo everything. This also enables the option to choose the artifacts from a given build. You can select last finished build (if no more builds happen), last pinned build (then you would need to pin the build during the build or the deploy to staging steps), and several other options that would allow you to pick exactly the builds you need.

Could you check whether this helps in your situation?

Hi Denis,

Thanks for you reply. We indeed have a separate build step but I forgot to mention in my initial post that we also run this build in monday sometimes to test it in staging. This is where it goes wrong as production then gets the latest release instead of the release from monday morning.

That's why I was hoping that I could somehow lock the production release to a build chain that starts on monday morning with the build and the release to staging. If I understand correctly, that is a feature you currently don't support?

We are considering an alternative now in that we create two build chains: one manual for testing purposes and one automated. The automated one is then never rebuild on monday and production would get the same version as staging did the day before. I'm curious if you have any better ideas: otherwise I'll make sure to create a feature request.

Thanks,

Sander

Hi Sander,

Several of the options of the artifact dependency allow you to not reuse the last build. You can pin the build, and use the "last pinned build". You could even automate the build pinning via the REST API in a snapshot dependency of the appropriate build.

Creating a separate build (out of a template or meta runner) for testing purposes definitely makes sense and isolates the different options, you would have an automated deployment without being messed by the testing you want to manually make, but using features like build pinning you can still automate it without the split.

There is other ways to do it. You could set up a new build step after the staging deployment that runs a script that simply triggers a 24h (or similar) wait and then uploads to production. This would definitely be a workaround, not particularly comfortable, but it should do the job.

You could set the artifact dependency to use "build with specified build number", specify a parameter, then set up a build that uses the REST API to set the build number to take the artifact from.

There are probably more workarounds, but I would definitely suggest using the build pinning, especially if you can automate the pinning, and/or use a separate build configuration for manual testing.