This is one of the ugliest parts; we need an extra parameter to support
the irregular screds/dcreds aliases.
This was previously unsupported by (skopeo layers).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
We don't want to worry about mismatch of the flagPrefix value
between imageFlags() and contextFromImageOptions(). For now,
record it in imageOptions; eventually we will stop using it in
contextFromImageOptions and remove it again.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This is similar to the previous *Options structures, but this one
will support differing sets of options, in particular for the
copy source/destination.
The way the return values of imageFlags() are integrated into
creation of a cli.Command forces fakeContext() in tests to do
very ugly filtering to have a working *imageOptions available
without having a copyCmd() cooperate to give it to us. Rather
than extend copyCmd(), we do the filtering, because the reliance
on copyCmd() will go away after all flags are migrated, and so
will the filtering and fakeContext() complexity.
Finally, rename contextFromGlobalOptions to not lie about only
caring about global options.
This only introduces the infrastructure, all flags continue
to be handled in the old way.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
contextFromGlobalOptions now uses globalOptions instead
of cli.Context.Global* . That required passing globalOptions
through a few more functions.
Now, "all" that is left are all the non-global options
handled in contextFromGlobalOptions.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Replace commandTimeoutContextFromGlobalOptions with
globalOptions.commandTimeoutContext. This requires passing
globalOptions to more per-command *Options state.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
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>
