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 [email protected]. 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.
