This works just like the command-specific options. Handles only
the single flag for now, others will be added as the infrastructure
is built.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This works just like the command-specific options. Also
moves the "Before:" handler into a separate method.
Does not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Use Destionation: &opts.flag in the flag definition
instead of c.String("flag-name") and the like in the hadler and
matching only by strings.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This is a big diff, but it really only replaces a few global variables
with functions returning a structure.
The ultimate goal of this patch set is to replace option handling using
> cli.StringFlag{Name:"foo", ...}
> ...
> func somethingHandler(c *cli.Context) error {
> c.String("foo")
> }
where the declaration and usage are connected only using a string constant,
and it's difficult to notice that one or the other is missing or that the
types don't match, by
> struct somethingOptions {
> foo string
> }
> ...
> cli.StringFlag{Name:"foo", Destination:&foo}
> ...
> func (opts *somethingOptions) run(c *cli.Context) error {
> opts.foo
> }
As a first step, this commit ONLY introduces the *Options structures,
but for now empty; nothing changes in the existing implementations.
So, we go from
> func somethingHandler(c *cli.Context error {...}
>
> var somethingCmd = cli.Command {
> ...
> Action: somethingHandler
> }
to
> type somethingOptions struct{
> } // empty for now
>
> func somethingCmd() cli.Command {
> opts := somethingOptions{}
> return cli.Command {
> ... // unchanged
> Action: opts.run
> }
> }
>
> func (opts *somethingOptions) run(c *cli.context) error {...} // unchanged
Using the struct type has also made it possible to place the definition of
cli.Command in front of the actual command handler, so do that for better
readability.
In a few cases this also broke out an in-line lambda in the Action: field
into a separate opts.run method. Again, nothing else has changed.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
It's probably not strictly necessary, but let's work with the current
implementation before worrying about possible idiosyncracies.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Before we use "go get" in CI, run "go version" so that we can be sure of
which version of the toolchain we're using.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
github.com/containers/image/copy.Image() now returns the copied
manifest, so we at least need to ignore it.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Bump github.com/containers/image to version
5e5b67d6b1cf43cc349128ec3ed7d5283a6cc0d1, which modifies copy.Image() to
add the new image's manifest to the values that it returns.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Temporarily vendor opencontainers/image-spec from a fork
to fix "id" value duplication, which is detected and
refused by gojsonschema now
( https://github.com/opencontainers/image-spec/pull/750 ).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... which has, apparently, never worked, because the golang image
has neither the GOPATH nor the working directory the Makefile expects.
Rather than move all this configuration into the Makefile to be able
to work with the golang images, just always use the skopeobuildimage
path, and only override the tags, to minimize divergence.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Instead, use DockerReference() to obtain the repository name (which
also makes it work for other transports that support Docker references),
and a check for docker.Transport + docker.GetRepositoryTags.
This will allow dropping docker.Image from containers/image, and maybe
even all of ImageReference.NewImage (forcing callers to think about
manifest lists, among other things).
