Turn of go modules to avoid breaking build environments to accidentally
try pulling the dependencies instead of using the ./vendor directory.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Add a `go-get` function to the Makefile to wrap `go get -u` into a
wrapper disabling go modules.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
An issue for achieving reproducible builds is build artifacts where
build paths are embedded. We remove them by passing the current working
directory to -gcflags and -asmflags which prefix trims the paths.
Note: Go 1.13 includes `-trimpath`
https://reproducible-builds.org/docs/build-path/
Signed-off-by: Morten Linderud <morten@linderud.pw>
Build artifacts embeds the current date of the build into the artifact.
If anyone want to reproduce the software at a later date there is no way
to pass a recorded date or fake it in the build system at a later point.
https://reproducible-builds.org/docs/source-date-epoch/
Signed-off-by: Morten Linderud <morten@linderud.pw>
I'm running the BATS tests manually once in a while, and
catching several problems each week that make it past
the rest of CI. Since the BATS tests run at RPM gating
time, we need to catch problems earlier. Try running
the tests from Cirrus.
Tests will be skipped on Ubuntu due to a too-ancient
version of coreutils (8.28; the 'timeout -v' we use
requires 8.29).
Tests are run *after* integration tests, even though
these take three minutes and would be nice to have
fail quickly, because running before causes bizarre
CI failures. Shrug.
UPDATE: also fix run test, broken by #3311.
Signed-off-by: Ed Santiago <santiago@redhat.com>
- PREFIX is now passed saved in the binary at build-time so that default
paths match installation paths.
- ETCDIR is also overridable in a similar way.
- DESTDIR is now applied on top of PREFIX for install/uninstall steps.
Previously, a DESTDIR=/foo PREFIX=/bar make would install into /bar,
rather than /foo/bar.
Signed-off-by: Lawrence Chan <element103@gmail.com>
For people who want to install podman remote or podman
only we need to separate out the two install commands.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We want the remote tests for our distributions to be tested in a
different VM than the local tests. This allows for faster CI runs and
easier debug as well as seperation of flakes.
Signed-off-by: baude <bbaude@redhat.com>
If the systemd development files are not present on the system which
builds podman, then `podman events` will error on runtime creation.
Beside this, a warning will be printed when compiling podman.
This commit mainly exists because projects which depend on libpod
would not need the podman event support and therefore do not need to
rely on the systemd headers.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
Existing code was not working due to a bash gotcha ('exit'
from a pipeline). It also had unnecessary duplication.
New version is safer; also includes unit tests run under localunit.
Existing invocations of req_env_var replaced via:
$ [ edit setup_environment.sh, move one closing quote to its own line ]
$ perl -ni -e 's/(?<=req_env_var )"(\S+)\s+\$\1"/$1/; if (/req_env_var "$/ .. /^\s*"/) { chomp; s/(?<=\S)\s.*//; if (/^\s*"/) { print "\n" } else { unless (/req_env_var/) { s/^\s+//; print " ";} print;} } else { print }' $(ack -l req_env_var)
$ [ hand-massage an incorrect instance of '@' in lib.sh:ircmsg() ]
Signed-off-by: Ed Santiago <santiago@redhat.com>
build a podman-remote binary for windows that allows users to use the
remote client on windows and interact with podman on linux system.
Signed-off-by: baude <bbaude@redhat.com>
Weekend hack by someone who doesn't grok zsh completion
but who finds it deeply offensive that most completion
files have an unmaintainable duplication of options
and arguments. The idea behind this one is to discover
the command line using --help, with a few hardcoded
helpers for discovering containers, images, pods,
and figuring out which args take files/dirs as args.
Working remarkably well. I am using this in my daily
routine and wondering how I ever managed without it.
It's not perfect -- a future version can perhaps
show only stopped containers for podman rm, only
running ones for podman stop -- but ROI seems low
on that given my limited zsh completion skills.
Sadly, I can't figure out how to write a regression
test suite for this. It would be lovely to have a
list if partial command lines and expected completions,
because the history of this change is that (seemingly)
minor tweaks in one place cause breakage in another.
Does anyone know of such a framework?
Still... working well enough to ship, IMO.
Signed-off-by: Ed Santiago <santiago@redhat.com>
to protect against regressions, we need to add a few gating tasks:
* build with varlink
* build podman-remote
* build podman-remote-darwin
we already have a gating task for building without varlink
Signed-off-by: baude <bbaude@redhat.com>
It also causes conflicts with CRI-O packages.
Also, change the path on seccomp.json so it lives in /usr/share
by default, with everything else.
Fixes#2596
Signed-off-by: Matthew Heon <mheon@redhat.com>
a series of improvements to our ginkgo test framework so we can
get better ideas of whats going on when run in CI
Signed-off-by: baude <bbaude@redhat.com>
when gopath was not explicitly set, make would fail due
to the varlink generator. this symlink in the makefile
addresses that.
fixes: #1842
Signed-off-by: baude <bbaude@redhat.com>
This is the final cleanup to remove urfave/sli from libpod. Removed
old, disabled tests that have not been run in over a year.
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>
@baude and I have recently debugged a `make vendor` issue, where
different versions of `vndr` leave slightly different states behind.
This ultimately leads to inconsistencies with the CI, which always
fetches the latest version.
To avoid such issues in the future, always use the latest version of
`vndr` by checking for new versions of it prior to execution.
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Generate make helping message dynamicaly by using
python code snippet inside Makefile.
All commented make targets will be added to the
help message. To be added to the helping message
comment need to start with '## '.
These specials comments are detected by the python code.
Python code generate the helping output from these results.
Notice that this commit introduce a dependency with python (compatible python 2 and 3).
Signed-off-by: Hervé Beraud <hberaud@redhat.com>
PR #2259 removed the .install.gomega Makefile target but
didn't clean up two references to it. Do so now.
Also, when setting up GOPKGBASEDIR symlink, use -f (force)
flag; otherwise subsequent makes will fail.
Signed-off-by: Ed Santiago <santiago@redhat.com>
* Make sure that all vendored dependencies are in sync with the code and
the vendor.conf by running `make vendor` with a follow-up status check
of the git tree.
* Vendor ginkgo and gomega to include the test dependencies.
Signed-off-by: Chris Evic <cevich@redhat.com>
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
IMHO, longer than this waiting for automated testing is "too long".
Scientificaly speaking, based on thousands of runs across many
platforms, successful runs always happen in less time. Normally
Ubuntu passes in 35-40 minutes, and the Fedoras do it in 25-30.
If they take longer, something is likely badly broken. In that
case, it's better to fail within a short/defined time, than wait
for the (much longer) automation-level timeout and inevitable
failure.
Signed-off-by: Chris Evich <cevich@redhat.com>
