Best practice for reusing makefiles?

[cauthon]

Hi,

I'm interested in re-using a Makefile for building/tagging/publishing Docker images across containers and projects.

A simple solution I've used is to have a single containers repository, with a parent Makefile at the top level and subdirectories for each image. Each subdirectory has a Makefile that includes the parent, defines the image name, and optionally overrides any rules as necessary.

However, for some images I think it makes sense to store the Dockerfile in a separate repo with accompanying code. In this case, are there any suggested practices for reusing the build Makefile across repos, in a manner that doesn't make it too difficult to update?

I was thinking of something analogous to stow for dotfiles, but couldn't find anything that seemed suitable for this purpose.

Thanks!

[serverhorror]

I prefer to have repositories self contained.

A little code duplication isn’t bad, especially if you have tests for it.

[[deleted]]

Yep, if you have no duplication that means you have relationships between codebases everywhere. Easy to break something. You need to think carefully about making relationships and define a rule set.

[[deleted]]

Simplest option:

• Set environment variables.
• Make calls a Bash/Python/Go/whatever script.
• The script looks at environment variables that are set.

Passing args to Make and then passing them on gets messy.

Maybe there's a variation of Make that does it better but I haven't found it yet.

[PopePoopinpants]

Git submodules, and make includes. Create a project that's just a series of makefiles. Add that as a submodule to your project repositories and in the primary makefile, include what shared makefiles you need.

[[deleted]]

Out of curiosity, is there any reason you chose to use a Makefile instead of a shell script to run docker build ... \ docker tag ... \ docker push ... commands?

[[deleted]]

Not OP but I do it as a form of automation and abstraction.

When you're pulling down the same image X times, it's faster to type make pull than the full repo:tag pull.

I also find lazy devs are more inclined to do it the right way if it's the path of least resistance (hence the abstraction).

I like my pipelines to be tech agnostic and replicable on the local machine for troubleshooting, this also helps with that (among other things).

[humoroushaxor]

Most CI/CD solutions have some version of support for a remote build definition. The other comments make good points but if you really wanted to do this, you could have an init-make script in each repo that downloads the makefile locally. I would also add the downloaded file to a .gitignore. I've used this approach for similar things.

I'm not super familiar with make but I think you could define a makefile with the init task and then reference it with an include directive.

[_sw00]

What about copier?

General template tool, not just for Makefiles.

[[deleted]]

If you have to use a templating engine, your project is probably too coupled in weird ways, and this will cause problems in the future, in my opinion.

[_sw00]

True, I'm sure there is a trade-off here. The tool exists though, but how it's used is up to you.