| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
| |
Building multi-arch images in a standardized way is complex. Some
of the builds themselves can take a really long time to run (over
an hour). Make changes easier to test inside a PR by adding
manually-triggered image-build tasks. These mirror most of the real
cron-triggered task, without actually pushing the final images.
Signed-off-by: Chris Evich <cevich@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In general continuous-delivery (CD) tends to pair well with CI. More
specifically, there is a need for some reverse-dependency CI testing in
netavark/aardvark-dns. In all cases, the download URL needs to remain
consistent, without elements like `Build%20for%20fedora-35`.
The 'Total Success' task only ever executes when all dependencies are
successful. When a non `[CI:DOCS]` build is successful, gather all
binary/release artifacts in a new task which depends on 'Total Success'.
This will provide a uniform name (`artifacts`) and URL for downstream
users to use. For example:
https://api.cirrus-ci.com/v1/artifact/github/containers/podman/artifacts/binary.zip
or
https://api.cirrus-ci.com/v1/artifact/github/containers/podman/artifacts/binary/FILENAME
Where ***FILENAME*** is one of:
* `podman`
* `podman-remote`
* `rootlessport`
* `podman-release-386.tar.gz`
* `podman-release-amd64.tar.gz`
* `podman-release-arm64.tar.gz`
* `podman-release-arm.tar.gz`
* `podman-release-mips64le.tar.gz`
* `podman-release-mips64.tar.gz`
* `podman-release-mipsle.tar.gz`
* `podman-release-mips.tar.gz`
* `podman-release-ppc64le.tar.gz`
* `podman-release-s390x.tar.gz`
* `podman-remote-release-darwin_amd64.zip`
* `podman-remote-release-darwin_arm64.zip`
* `podman-remote-release-windows_amd64.zip`
* `podman-v4.0.0-dev.msi`
Signed-off-by: Chris Evich <cevich@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reimplement CI-automation to remove accumulated technical-debt and
optimize workflow. The task-dependency graph designed goal was to
shorten it's depth and increase width (i.e. more parallelism). A
reduction in redundant building (and 3rd party module download) was
also realized by caching `$GOPATH` and `$GOCACHE` early on. This
cache is then reused in favor of a fresh clone of the repository
(when possible).
Note: The system tests typically execute MUCH faster than the
integration tests. However, contrary to a fail-fast/fail-early
principal, they are executed last. This was implemented due to
debug-ability related concerns/preferences of the primary
(golang-centric) project developers.
Signed-off-by: Chris Evich <cevich@redhat.com>
|
| |
|
|
|
|
|
|
| |
The initial implementation was far more complicated than necessary.
Strip out the complexities in favor of a simpler and more direct
approach.
Signed-off-by: Chris Evich <cevich@redhat.com>
|
|
|
The release-task ***must*** always execute last, in order to guarantee a
consistent cache of release archives from dependent tasks. It
accomplishes this by verifying it's task-number matches one-less than
the total number of tasks. Previous to this commit, a YAML anchor/alias
was used to avoid duplication of the dependency list between 'success'
and 'release'
However, it's been observed that this opens the possibility for
'release' and 'success' tasks to race when running on a PR. Because
YAML anchor/aliases cannot be used to modify lists, duplication is
required to make 'release' actually depend upon 'success'.
This duplication will introduce an additional maintenance burden.
Though when adding a new task, it's already very easy to forget to
update the 'depends_on' list. Assist both cases by the addition
unit-tests to verify ``.cirrus.yml`` dependency contents and structure.
Signed-off-by: Chris Evich <cevich@redhat.com>
|
