Thanks Martin. I will explore tagging my docker images as we deploy them. So if I deploy dockerUrl/atrifact:1.0.0 to sandbox, I'll give it a dockerUrl/artifact:1.0.0-sandboxed tag. My deploy-to-staging job will then have to "look" for the "sandboxed" part in the tag.
Chris On Monday, November 12, 2018 at 6:14:52 PM UTC-5, Martin d'Anjou wrote: > > I think you could use the Copy Artifacts > <https://wiki.jenkins.io/display/JENKINS/Copy+Artifact+Plugin> plugin to > share a file between jobs. But managing the list of releases in a file > becomes hairy IMO. I do not know your specific case, but I guess it will > grow over time, not to millions of records, but possibly to hundreds or > maybe thousands. There is also the question of rollbacks in case of > uncontrollable mistakes (how to erase an entry from the list). > > You could use a shared workspace for the purpose of storing that file, > using the external workspace manager plugin > <https://github.com/jenkinsci/external-workspace-manager-plugin/blob/master/README.md> > . > > I would consider an external database of some kind and the httpRequest > <https://jenkins.io/doc/pipeline/steps/http_request/> plugin to access it. > > If you push your releases to a binary repository, there could be a way to > store that info there too. > > Martin > > On Monday, November 12, 2018 at 9:00:36 AM UTC-5, ZillaYT wrote: >> >> Thanks Martin, though you just reworded my post. >> >> But yes one approach to consider is being able to store which, for >> example, versions have been run by deploy-to-sandox. IOW if >> deploy-to-sandbox has run with versions 1.0.0 and 1.0.4, I want to store >> those versions in its property file, say sandboxed_versons.properties. How >> will I then tell deploy-to-staging to read >> /.../deploy-to-sandbox/sandboxed.properties file? >> >> Chris >> >> On Saturday, November 10, 2018 at 9:35:12 PM UTC-5, Martin d'Anjou wrote: >>> >>> 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 >>> >> -- 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/57be66d4-ad61-4e7a-b3b7-237883e83b87%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
