Setting docker image version based on .ruby-version?


#1

Hello,

I’m migrating one of our projects to CircleCI v2. I got most of the stuff right, except that there is one regression in terms of features.

In the past, the correct Ruby version was installed on CircleCI based on the .ruby-version file, which reflects our production setting.

Currently we have to manually define the version using:

- image: circleci/jruby:9.1.14.0

(but this value is already in .ruby-version).

This means that one person modifying .ruby-version will have to remember to also update the CircleCI configuration, which is error prone and could lead to undetected regressions in the codebase (of course, we will add a unit test to lock that down, but other people may be less careful).

Is there a way to tell CircleCI v2 to dynamically extract the docker image name from .ruby-version, maybe something like this?

- image: circleci/jruby:{{ file_content '.ruby-version' }}

Thanks in advance for any hint you’ll be able to provide to help us DRY the configuration here & complete our v2 migration.

– Thibaut


#2

I too would like an elegant solution to this as we migrate to Circle 2.0.

I wonder if there will be opportunity to ask questions during the upcoming “Introduction to .circleci/config.yml’” webinar.


#3

This is not currently a feature via the Docker executor. You can spin up a Docker image in this fashion using the machine executor but that’s a completely different ballgame.

I think this feature is very useful and I’d suggest submitting as a feature request to https://circleci.com/ideas.


#4

If your tests can check they are the same, the only inconvenience you’ll have is that you’ll have is a failed build that needs repairing. You could do this early in the build process, so it is sure to fail after 20 seconds, rather than doing in your test bank where the wait might be longer.


#5

I know how to fix it for myself, no problem! I’m more concerned about other people migrating from v1 to v2, and for which this will come as a downgrade in a way (although a manageable one).

This can be made DRY with a simple “preprocessing filter”.

Thanks @FelicianoTech I’ll submit this as an idea.


#6

I like that idea. I’ve mentioned it before here - if we could get a call to .circleci/pre-hook.sh or similar prior to CircleCI doing its work, there’d be all sorts of YAML rewrites folks could do. Env vars are not supported throughout the format, so that would be a pretty nice workaround.


#7

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.