| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Added support for system service
* Enabled linting on the varlinkapi source, needed to support V2
service command
* Added support for PODMAN_SOCKET
Skip linting deprecated code
Rather than introduce bugs by correcting deprecated code, linting the
code is being skipped. Code that is being ported into V2 is being
checked.
Signed-off-by: Jhon Honce <jhonce@redhat.com>
|
|
|
|
|
|
|
|
| |
Correct mistake that broke things like dlv where we should only
try to add the varlink command to podman when the 'varlink' build
tag is present.
Signed-off-by: baude <bbaude@redhat.com>
|
|
|
|
|
|
|
|
| |
We intend to migrate to the cobra cli from urfave/cli because the
project is more well maintained. There are also some technical reasons
as well which extend into our remote client work.
Signed-off-by: baude <bbaude@redhat.com>
|
|
some platforms and operating systems do not have varlink. in those cases,
we need to be able to turn off enablement of varlink in podman. this can now
be done with BUILDTAGS passed to the build though perhaps in the future
will be better.
the default is to build with varlink
Signed-off-by: baude <bbaude@redhat.com>
squash! make varlink optional for podman
The API.md and cmd/podman/varlink/ioprojectatomicpodman.go targets
will continue to work regardless of the presence (or not) of 'varlink'
is in BUILDTAGS. However, cmd/podman/varlink/ioprojectatomicpodman.go
is now only required by the podman target when BUILDTAGS contains
'varlink'.
API.md had also been an podman dependency since 5b2627dd (Makefile:
Drop find-godeps.sh for podman target, 2018-05-15, #776) when I
expanded varlink_api_generate. It had been an indirect podman
dependency (via varlink_api_generate) since 25263558 (Generate varlink
API documentation automatically, 2018-05-07, #734). But the podman
executable obviously doesn't depend on the Markdown file, so I'm
removing that dependency here.
Signed-off-by: baude <bbaude@redhat.com>
squash! make varlink optional for podman
The command-pointer approach will scale well if/when we add additional
optional commands behind their own build tags, because those tags
won't all be competing for the same getOptionalCommands namespace.
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes: #987
Approved by: rhatdan
|