search

decidim / docker

Docker images for decidim
https://decidim.org
12 stars 18 forks source link

Release a `development` tag #84

Open mrcasals opened 3 years ago

mrcasals commented 3 years ago

I'm trying to deploy our staging app using Docker, and it's using decidim/decidim:latest as its source image. Unfortunately, this means it's using the docker version for v0.23.2, which uses Ruby 2.6.6, but my staging app needs Ruby 2.7.1.

How should we approach this?

mrcasals commented 3 years ago

@oliverbarnes any idea? 😄

oliverbarnes commented 3 years ago

I started working on a branch-based build back in December (https://github.com/decidim/docker/pull/61), but dropped it after discussing it with @andreslucena - at that point it didn't seem like a core concern, as opposed to a vendors' one.

At @liquidvotingio we're currently using a quick & dirty approach using the following Dockerfile based on a fork that has a custom stateless app generator:

RUN bundle exec rake decidim:generate_stateless_demo_app

...by stateless meaning it doesn't go through with the database steps.

It's a little different than the first attempt, which was more involved and would actually check out the repo during the docker build, rather than build from within the repo.

...Re-reading the title of the issue here though... are you suggesting creating a separate release tag for latest develop (or main, once renamed) on decidim/decidim, which would trigger an image build with the existing Dockerfiles here on decidim/docker? I think that could work!

But we might need to decide what we want the latest image tag to mean. Should it mean latest develop release, or latest version release? And if so, the github workflow building them should be updated accordingly

mrcasals commented 3 years ago

are you suggesting creating a separate release tag for latest develop (or main, once renamed) on decidim/decidim, which would trigger an image build with the existing Dockerfiles here on decidim/docker? I think that could work!

That's exactly it! 😄

But we might need to decide what we want the latest image tag to mean. Should it mean latest develop release, or latest version release? And if so, the github workflow building them should be updated accordingly

I don't have a clear opinion on this, rally 😕 Not sure what's the most usual approach on this!

oliverbarnes commented 3 years ago

I don't either :) These are interesting write-ups I found on the topic of docker image tagging:

https://vsupalov.com/docker-latest-tag/ https://vsupalov.com/docker-better-image-tags/

tldr - author warns against using latest in production, which is error prone (deployments getting stuck with stale images, or unexpected versions being deployed), and recommends being careful about "moving tags" (images tags that can point to different versions of an image) in general.

We already do a couple of things the author recommends, such as tagging the commit SHA and the semantic version (our Decidim version), in parallel to latest.

latest is docker build's default when no specific tag is given, and is what gets pulled automatically when running docker pull with no image tag. So if we did away with it, the latter flow would break. Anybody, or any CI, pulling the decidim image, would have to always explicitly state either the SHA or the Decidim version. Great for CIs and deployments, but a bit of a pain for human newcomers just wanting to spin up a decidim container locally to have a peek.

One thing I just realized is that our docker builds currently scrape the Decidim version out of the decidim/decidim Github release tags (removing the v out of v0.23.2 so one can pull decidim:0.23.2), so if we have a new release tag named develop, main or staging, that'll break. The build will need to be adapted for this new flow.

Just food for thought - I haven't arrived at a conclusion yet