contextFromImageOptions is finally not using any string-based lookup
in cli.Context, so we don't need to record this value any more.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This introduces YET ANOTHER *Options structure, only to share this
option between copy source and destination. (We do need to do this,
because the libraries, rightly, refuse to work with source and
destination declaring its own versino of the --authfile flag.)
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This is an extension of imageOptions that carries destination-specific
flags.
This will allow us to handle --dest-* flags without also exposing
pointless --src-* flags.
(This is, also, where the type-safety somewhat breaks down;
after all the work to make the data flow and availability explicit,
everything ends up in an types.SystemContext, and it's easy enough
to use a destination-specific one for sources. OTOH, this is
not making the situation worse in any sense.)
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
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>
