Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to get tools into the docker image #225

Open
cabo opened this issue May 13, 2020 · 6 comments
Open

How to get tools into the docker image #225

cabo opened this issue May 13, 2020 · 6 comments
Labels

Comments

@cabo
Copy link
Contributor

cabo commented May 13, 2020

https://travis-ci.org/core-wg/senml-versions fails, because the docker image does not contain tex2mail.

Now the usage of tex2mail in that document is a bit of a joke, but in other documents there are already uses of other tools external to kramdown-rfc such as goat and svg-check, and the list that kramdown-rfc "can" use will grow further.

I'm wondering what might be a good process to handle that growth. Does all this authoring stuff even belong in the docker image? I'd argue it does.

@martinthomson
Copy link
Owner

That's an interesting question. The way that I've resolved that in the past is to fork the docker image and use my own. Which is a little clumsy, of course.

There is an intermediate step where the docker image is a little more conducive to being built on top of. The switching to a user account in there makes it hard to do anything that requires root access.

For something trivial, adding prerequisites to the Makefile and installing on demand also works, but that isn't really the best option either.

I am reminded of the folly of frameworks, as opposed to libraries, and find myself hating the part where I end up maintaining a framework (ಥ﹏ಥ)

@martinthomson
Copy link
Owner

I now have a process that I'm trialing, at least for those on GitHub Actions. If, rather than the @v1 action, you use the @v1m action, you get access to a larger image, for which the bar for including additional tools is much lower. The image has a -math label, but I'm thinking that I will rename it to -mega instead. Most people don't need this sort of integration, so the @v1 can stay fast and lean. Opting for @v1m will mean that your builds are far less efficient, but it should be possible to include tools.

There is also the option of just adding an install step to builds, as described in the documentation.

@larseggert
Copy link
Contributor

FYI, recently I made https://github.com/larseggert/i-d-toolchain, which tries to install "all the tools". A fresh image is built every six hours with the latest versions.

@larseggert
Copy link
Contributor

Wondering if I should scrap my image and instead use your (possibly extended) meta image...

@martinthomson
Copy link
Owner

Upcoming work will let you specify prerequisites in a requirements.txt/Gemfile/package.json (or all of these) and have them automatically installed (and cached in CI builds). This should help relieve pressure on the docker images.

@thomas-fossati
Copy link

Upcoming work will let you specify prerequisites in a requirements.txt/Gemfile/package.json (or all of these) and have them automatically installed (and cached in CI builds). This should help relieve pressure on the docker images.

Just FYI, re: adding extra packages via Gemfile, I'm having troubles with the Ruby environment installed in the Docker images (both v1 and v1m). See #344

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants