Let's take advantge of an existing action that publishes the payload
after each pull request, to also publish the "builder images" used to
build each one of the artefacts.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
There was a typo in the registry name, which should be
quay.io/confidential-containers/runtime-payload-ci instead of
quay.io/repository/confidential-containers/runtime-payload-ci
Fixes: #5469
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's create a GitHub action to automate the Kata Containers payload
generation for the Confidential Containers project.
This GitHub action builds the artefacts (in parallel), merges them into
a single tarball, generates the payload with the resulting tarball, and
uploads the payload to the Confidential Containers quay.io.
It expects the tags to be used to be in the `CC-x.y.z` format, with x,
y, and z being numbers.
Fixes: #5330
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's have a GitHub action to publish the Kata Containers payload, after
every push to the CCv0 branch, to the Confidential Containers
`runtime-payload-ci` registry.
The intention of this action is to allow developers to test new
features, and easily bisect breakages that could've happened during the
development process. Ideally we'd have a CI/CD pipeline where every
single change would be tested with the operator, but we're not yet
there. In any case, this work would still be needed. :-)
It's very important to mention that this should be carefully considered
on whether it should or should not be merged back to `main`, as the flow
of PRs there is way higher than what we currently have as part of the
CCv0 branch.
Fixes: #5460
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This reverts commit 7676cde0c5.
It turns out that when triggerred from a PR, the docker login command is
failing with
```
Error: Cannot perform an interactive login from a non TTY device
```
Signed-off-by: Peng Tao <bergwolf@hyper.sh>
Adds cargo-deny to scan for vulnerabilities and license issues regarding
rust crates.
GitHub Actions does not have an obvious way to loop over each of the
Cargo.toml files. To avoid hardcoding it, I worked around the problem
using a composite action that first generates the cargo-deny action by
finding all Cargo.toml files before calling this new generated action in
the master workflow.
Uses recommended deny.toml from cargo-deny repo with the following
modifications:
ignore = ["RUSTSEC-2020-0071"]
because chrono is dependent on the version of time with the
vulnerability and there is no simple workaround
multiple-versions = "allow"
Because of the above error and other packages, there are instances
where some crates require different versions of a crate.
unknown-git = "allow"
I don't see a particular issue with allowing crates from other repos.
An alternative would be the manually set each repo we want in an
allow-git list, but I see this as more of a nuisance that its worth.
We could leave this as a warning (default), but to avoid clutter I'm
going to allow it.
If deny.toml needs to be edited in the future, here's the guide:
https://embarkstudios.github.io/cargo-deny/index.htmlFixes#3359
Signed-off-by: Derek Lee <derlee@redhat.com>
An implementation of semi-automating the backporting
process.
This implementation has two steps:
1. Checking whether any associated issues are marked as bugs
If they do, mark with `auto-backport` label
2. On a successful merge, if there is a `auto-backport` label and there
are any tags of `backport-to-BRANCHNAME`, it calls an action that
cherry-picks the commits in the PR and automatically creates a PR to
those branches.
This action uses https://github.com/sqren/backport-github-actionFixes#3618
Signed-off-by: Derek Lee <derlee@redhat.com>
To keep runtime-rs up to date, we will merge main into runtime-rs every
week.
Fixes:#4776
Signed-off-by: Zhongtao Hu <zhongtaohu.tim@linux.alibaba.com>
repository_owner check in docs-url-alive-check.yaml now is specified for each step, it can be in job level to save lines.
Fixes: #4611
Signed-off-by: Yuan-Zhuo <yuanzhuo0118@outlook.com>
Recently added check-commit-message to the tests repository. Minor
changes were also made to action. For consistency's sake, copied changes
over to here as well.
tests - https://github.com/kata-containers/tests/pull/4878
Minor Changes:
1. Body length check is now 75 and consistent with guidelines
2. Lines without spaces are not counted in body length check
Fixes#4559
Signed-off-by: Derek Lee <derlee@redhat.com>
`snap`/`snapcraft` seems to have changed recently. Since `snap`
auto-updates all `snap` packages and since we use the `snapcraft` `snap`
for building snaps, this is impacting all our CI jobs which now show:
```
Installing Snapcraft for Linux…
snapcraft 7.0.4 from Canonical* installed
Run snapcraft -d snap --destructive-mode
Usage: snapcraft [options] command [args]...
Try 'snapcraft pack -h' for help.
Error: unrecognized arguments: -d
Error: Process completed with exit code 1.
```
Move the debug option to make it a sub-command (long) option to resolve
this issue.
Fixes: #4457.
Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
Some generated merge commit messages are >75 chars
Allow these to not trigger the subject line length failure
Signed-off-by: Liu Jiang <gerry@linux.alibaba.com>
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
this will require to set a PR number when triggering the test-kata-deploy workflow manually
also make sure user variables are set correctly when workflow_dispatch is used
Fixes: #4349
Signed-off-by: Snir Sheriber <ssheribe@redhat.com>
As already done for the other assets we rely on, let's build (well, pull
in this very specific case) the virtiofsd binary, as we're relying on
its standlone rust version from now on.
Fixes: #4234
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This workflow is a scheduled job that runs at 23:00
every Sunday, it should only run the main repo
but not the forked ones.
Fixes: #4219
Signed-off-by: Bin Liu <bin@hyper.sh>
Instead of only vendoring the code needed by the agent, let's ensure we
vendor all the needed rust code, and let's do it using the newly
introduced enerate_vendor.sh script.
Fixes: #3973
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
'make kata-tarball' sometimes fails early with:
cp: cannot create regular file '[...]/tools/packaging/kata-deploy/local-build/dockerbuild/install_yq.sh': File exists
This happens because all assets are built in parallel using the same
`kata-deploy-binaries-in-docker.sh` script, and thus all try to copy
the `install_yq.sh` script to the same location with the `cp` command.
This is a well known race condition that cannot be avoided without
serialization of `cp` invocations.
Move the copying of `install_yq.sh` to a separate script and ensure
it is called *before* parallel builds. Make the presence of the copy
a prerequisite for each sub-build so that they still can be triggered
individually. Update the GH release workflow to also call this script
before calling `kata-deploy-binaries-in-docker.sh`.
Fixes#3756
Signed-off-by: Greg Kurz <groug@kaod.org>