Add the ability to clean the cache so that old images don't cruft up the cache. It should also have the ability to just delete the cache entirely, that way the user can always reset if they wish.

It makes for less typing and it's easier to type and keep control of.

Add support for TTY because Non-GNU wget does not support removing only the progress bar, so it is enabled, it would be nice if non-build server builds could display that as a progression like it's intended since non-GNU wget again does not detect TTY and disable it.

tty: true

docker-template template --tty

Where --tty overrides everything and tty:true is true unless --no-tty is set.

This will simplify what we have to do with @repo.buildable?, slightly perf our build and make life generally easier to manage now that we have setup and teardown.

Detect if there is a copy and opts.yml file directly inside of the current folder and setup accordingly.

These inhibit the ability for people to build other types of custom builders that do all sorts of nice things, remove these methods entirely along with image types and simply implement Builder#matches? so that builders can determine whether they will be the builder.

Technically the img and the repo are not parents, we they are aliases of one another, reflect that.

When metadata is aliased in some way and has it's own scopable values it should be treated as a normal build rather than an aliased build that aliases a tag, it is simply just aliasing values within a build and should be treated as a normal build.

In relation to envygeeks/jekyll-docker#90 and its missing rsync-package, I thought I'd post the bug here so that we could perhaps get it added sooner rather than later. :)

/home/thor/.bundler/ruby/2.3.0/docker-template-5bda91ef4e31/lib/docker/template/metadata.rb:441:in `method_missing': undefined method `as_hash' for #<Docker::Template::Metadata:0x00000002d97f40> (NoMethodError)
    from (erb):4:in `_binding'
    from /usr/lib/ruby/2.3.0/erb.rb:864:in `eval'
    from /usr/lib/ruby/2.3.0/erb.rb:864:in `result'
    from /home/thor/.bundler/ruby/2.3.0/docker-template-5bda91ef4e31/lib/docker/template/normal.rb:35:in `copy_dockerfile'
    from /home/thor/.bundler/ruby/2.3.0/docker-template-5bda91ef4e31/lib/docker/template/normal.rb:23:in `setup_context'
    from /home/thor/.bundler/ruby/2.3.0/docker-template-5bda91ef4e31/lib/docker/template/builder.rb:194:in `block in setup'
    from /home/thor/.bundler/ruby/2.3.0/docker-template-5bda91ef4e31/lib/docker/template/builder.rb:192:in `map'
    from /home/thor/.bundler/ruby/2.3.0/docker-template-5bda91ef4e31/lib/docker/template/builder.rb:192:in `setup'
    from /home/thor/.bundler/ruby/2.3.0/docker-template-5bda91ef4e31/lib/docker/template/builder.rb:127:in `build'
    from /usr/lib/ruby/2.3.0/set.rb:306:in `each_key'
    from /usr/lib/ruby/2.3.0/set.rb:306:in `each'
    from /home/thor/.bundler/ruby/2.3.0/docker-template-5bda91ef4e31/lib/docker/template/cli.rb:24:in `map'
    from /home/thor/.bundler/ruby/2.3.0/docker-template-5bda91ef4e31/lib/docker/template/cli.rb:24:in `block in build'
    from /home/thor/.bundler/ruby/2.3.0/docker-template-5bda91ef4e31/lib/docker/template/cli.rb:86:in `with_profiling'
    from /home/thor/.bundler/ruby/2.3.0/docker-template-5bda91ef4e31/lib/docker/template/cli.rb:23:in `build'
    from /usr/lib/ruby/gems/2.3.0/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
    from /usr/lib/ruby/gems/2.3.0/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
    from /usr/lib/ruby/gems/2.3.0/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
    from /usr/lib/ruby/gems/2.3.0/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
    from /home/thor/.bundler/ruby/2.3.0/docker-template-5bda91ef4e31/bin/docker-template:25:in `<top (required)>'
    from /usr/lib/ruby/gems/2.3.0/bin/docker-template:23:in `load'
    from /usr/lib/ruby/gems/2.3.0/bin/docker-template:23:in `<main>'

The only thing that shouldn't be are opt hooks because they technically only extend and allow setting the configuration options via the opts, but things like verifying should have it's tests decoupled into specs for that specific hook.

This makes more sense since this is literally what we are doing, cleaning up after ourselves.

Request

I'm not sure if this is already supported but it'd be awesome to use docker-template to build for multiple architectures. Perhaps using something like the Docker buildx plugin would be best.

I'm not a Ruby user at all and only discovered docker-template today when attempting to build jekyll's Docker image on my M1 Macbook, but if I could use docker-template to build cross-architecture builds I would absolutely use docker-template for my personal projects.

Examples

Something like this would be really awesome:

docker-template buildx --platform linux/amd64,linux/arm64,linux/armhf ...

Anyway, not sure if this is all that feasible but if it was possible it would probably make things easier for users of docker-template to be able to deploy for more than one platform (unless it's already possible and I just missed it in the documentation).

Thanks for a super cool tool and any time spent looking at this request!

We have an inconsistency between key and method, this will confuse people looking at our source.

It would be nice that there be documentation for building projects with Docker-Template.

Hi! We have started using docker-template to manage various of our base images. It has been quite annoying to use bundler to install it (pointing to master). Specially because we need to instruct users not versed on Ruby. It would be great to have 0.9.0 released with the current code (master) on rubygems, so we would rather use 'gem install docker-template' system-wide.

Thanks! And congrats for your work.

• I tried updating to the latest version
  • I can't, there is an issue
  • This is about an < latest
    • I understand older versions may be unsupported
• I Am on Windows
  • Ubuntu Bash on Windows
  • Fedora Bash on Windows
  • Other Bash on Windows
• I Am on Linux
  • Ubuntu
  • Fedora
  • CentOS
  • Redhat
  • Debian
• I am on macOS 10.13
• I am on macOS 10.14
• I'm on Docker
  • I understand Docker may be unsupported

Description

The following Docker container (which in essence should be similar to a fresh Debian install with Ruby 3.x installed):

FROM ruby:3.2
RUN gem install docker-template

Produces the following output when running docker-template --help inside of it:

$ docker-template --help
/usr/local/bundle/gems/forwardable-extended-2.6.0/lib/forwardable/extended.rb:29:in `rb_delegate': wrong number of arguments (given 2, expected 1) (ArgumentError)
	from /usr/local/bundle/gems/extras-0.3.0/lib/extras/string.rb:12:in `<module:String>'
	from /usr/local/bundle/gems/extras-0.3.0/lib/extras/string.rb:10:in `<module:Extras>'
	from /usr/local/bundle/gems/extras-0.3.0/lib/extras/string.rb:9:in `<top (required)>'
	from <internal:/usr/local/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
	from <internal:/usr/local/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
	from /usr/local/bundle/gems/extras-0.3.0/lib/extras/all.rb:8:in `block in <top (required)>'
	from /usr/local/bundle/gems/extras-0.3.0/lib/extras/all.rb:7:in `each'
	from /usr/local/bundle/gems/extras-0.3.0/lib/extras/all.rb:7:in `<top (required)>'
	from <internal:/usr/local/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
	from <internal:/usr/local/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
	from /usr/local/bundle/gems/docker-template-0.22.0/lib/docker/template.rb:6:in `<top (required)>'
	from <internal:/usr/local/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
	from <internal:/usr/local/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
	from /usr/local/bundle/gems/docker-template-0.22.0/lib/docker/template/cli.rb:5:in `<top (required)>'
	from <internal:/usr/local/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
	from <internal:/usr/local/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
	from /usr/local/bundle/gems/docker-template-0.22.0/bin/docker-template:25:in `<top (required)>'
	from /usr/local/bundle/bin/docker-template:25:in `load'
	from /usr/local/bundle/bin/docker-template:25:in `<main>'

Same container running with Ruby 2.x (particularly 2.7) runs as expected:

$ docker-template --help
Commands:
  docker-template build [REPOS [OPTS]]  # Build all (or some) of your reposit...
  docker-template cache [REPOS [OPTS]]  # Cache all (or some) of your reposit...
  docker-template clean [REPOS [OPTS]]  # Clean all (or some) of your reposit...
  docker-template help [COMMAND]        # Describe available commands or one ...
  docker-template list [OPTS]           # List all possible builds.
  docker-template push [REPOS [OPTS]]   # Push all (or some) of your reposito...

Maybe set required Ruby version >= 2.1.0, < 3?

There is no reason for @copy to exist, all it does is cruft up the world.

Detect if the user is in repo/* and set the root accordingly so the user can build from sub-folders.

That way projects make sense.

Internal makes more sense and lets users know that a given builder is meant to be used internally.

If a user doesn't have a repo/*/opts.{yml,json} but has a global one it can lead to edges.

Metadata#as_gem_version _=>_ name@version

There is a lack of documentation because we aren't fully stable yet, once we get stable add Documentation and the documentation website to Github.

There is no reason for us to continue to use Metadata#[] when we can use the methods and allow some kind of fallback + queryables on actual variables we rely on, so you can have truly dynamic and shifting configurations.

Because Monkey patching is annoying it needs to be removed, I don't like it anyways.

Since we now support indifferent access, lets take advantage of symbols so the source is a tiny bit cleaner, this will provide no performance boost but it surely will make the code a little easier to read.

Right now we have the concept of build types, which are simply called and labeled "type" in the opts.yml but we also have the concept of tag types. This can lead to confusion, rename tag types to tag groups since that's pretty much what they are and move type to build_type so further reduce the surface of confusion.

Even though they look cleaner than others, for somebody who has just entered and is trying to check out our source, it can get rather confusing to try and read all that, add some comments, split it up, make it nice!