Tagging source code for extending images with versioning about rstudio-docker-products HOT 5 CLOSED

Thanks so much for reaching out here @darrenmedwards !! Do you mind my asking exactly what type of tagged versions you imagine?

Unfortunately just tagging the first build of the product at a particular version may not match the "last" way that we build that image, and updating the tag would not help at all for reproducibility of the source 😞

(i.e. when RSC first updates to 1.8.8.2, we will build it here. However, we may improve the Dockerfile or make changes to the code here before the next release of RSC lands. How would you expect tagging to work in that case?)

For instance, one way we could tag is just at the start of every month, create a 202101 tag, 202102 tag, etc. But that is also not super helpful since it will not necessarily correlate to the images. Does it work for you to pin to certain commits? Just whenever you pull / update the source, save the commit that you are referencing?

This is all partly a function of how we are using these images at present - which is not enormously reproducible. (i.e. our docker image tags are not immutable)

I'm not sure I am 100% understanding your use case, so am hopeful that discussing a bit more will help me understand 😄

from rstudio-docker-products.

For my purposes, I think it would be sufficient if the source code could be tagged with the same image tag and maybe some additional, immutable qualifier. I wouldn't need tags for non-release code

I think the image tags map to the RStudio product version and uses major.minor.patch-qualifier convention. Maybe the image build source code can be tagged with major.minor.patch-qualifier-unique_build_id (or maybe an incremental build #). So for example, the image tag 1.4.1106-5 could be built from git code tags 1.4.1106-5-1, 1.4.1106-5-2, and 1.4.1106-5-3

For my use case, this would allow me to create my own build pipeline that (1) pulls a tagged version of rstudio-docker-products, (2) performs a few regex find/replace on the Dockfile or other files, and (3) runs the docker build within my docker build environment. Also, with this methodology, I wouldn't have to fork the code that could potentially lead to drift. For better supportability purposes, this would allow me to stay tightly coupled with rstudio-docker-products... if that's ok 😄

Your idea to pin commits might work too, but I would just want to be sure the commit I'm using is stable and ideally tied to a released image tag.

Thanks for your engagement @colearendt!

from rstudio-docker-products.

Whew! Two weeks has passed already!? I thought I responded to this 🙈 Sorry about that!

Thanks for your patience! I like this idea / pattern a lot! Plus it could help us keep track of things in the repository a bit easier as well.

We are currently in the process of refactoring some of our repositories / CI processes. I suspect ultimately this type of incremental build # will probably be best implemented in CI so that it is consistent. Unfortunately it may take us a little while to get this rolling properly, but I am definitely hopeful that we can craft a good solution here!

from rstudio-docker-products.

We now publish docker images that have a SHA associated with them. The SHA is the git SHA of the code that produced them. Hopefully that is sufficient to accomplish this task! We do not have tagged releases (yet), but builds can be tracked against source code in this way.

from rstudio-docker-products.

Also, it's worth noting that we are nearing a state where not every git commit will build every image. We are hoping to only build images that "changed" / need to be built. So the workflow you describe where you start from a released image is still probably the best strategy in this case 😄

#255

from rstudio-docker-products.