I do not know of an automated way of doing that. If I understand correctly, the release number is assigned by the build-and-test phase, and it published the docker repo. I assume that this release number is known one way or another by the users, since it has been published to the docker repo. This release number is an input to the other jobs. So I suggest you make the release number an input parameter to the other jobs.
When each job runs, it needs to check that the released artifact has reached the expected "quality" level for the job. If not the jobs would fail with some meaningful error message. The quality levels would be 1) built and tested, 2) sandbox, 3) staging, and 4) production. In other words, deploy-to-sandbox(1.0.11) needs to check that the artifacts 1.0.11 exists in the docker repo before it attempts to deploy to sandbox. You also need to store the quality level somewhere persistent, maybe as a property of the artifacts in the docker repo (if that is possible?). Artifactory supports properties, or maybe you need a database. Hope this helps at least from a conceptual point of view. Martin On Friday, November 9, 2018 at 10:41:21 AM UTC-5, ZillaYT wrote: > > I have a folder with 4 jobs, namely, > > - build-and-test = a multi-branch pipeline job that builds and tests > code and, if successful, pushes a docker image to docker repo. So I can > have several versions of the docker image, say 1.0.0, 1.0.4, 1.0.11 > - deploy-to-sandbox = a pipeline job that pulls above docker image > from docker repo, with desired version from above build, and deploys it to > a sandbox environment > - deploy-to-staging = similarly, = a pipeline job that pulls above > docker image from docker repo, with desired version from above build, and > deploys it to a staging environment, ONLY IF desired version has been > deployed to sandbox already > - deploy-to-production = a pipeline job that pulls above docker image > from docker repo, with desired version from above build, and deploys it to > a production environment, ONLY IF desired version has been deployed to > staging already > > So I should ONLY be able to run deploy-to-production(1.0.4) if I've > already ran deploy-to-staging(1.0.4), and hence only if I've already ran > deploy-to-sandbox(1.0.4). One job does NOT automatically trigger any > downstream job. > > Also, I don't need to have the same version in all environments. For > example, I can have the scenario where... > > - deploy-to-sandbox(1.0.11) > - deploy-to-staging(1.0.4) > - deploy-to-production(1.0.0) > > ...again as long as what I'm deploying in production has already been > deployed to staging, and as long as that version has already been deployed > to sandbox. > > Any pointers on how to do this? > > Thanks! > Chris > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/e0a12ba8-4240-4cf3-bf53-0fd9d1ae0f31%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
