In workflow, `set-output` command is deprecated and will be disabled soon.
This commit replaces the deprecated `set-output` command with putting a
value in the environment file `$GITHUB_OUTPUT`.
Fixes#6266
Signed-off-by: jongwooo <jongwooo.han@gmail.com>
It is just to place a missing stage for permission adjustment in the
cc-payload-after-push-s390x workflow.
Fixes#6278
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
The version mentioned in the `kata_config_version` needs to be
updated for any kernel config change or changed to the patches applied.
Without this, CI would not test with the latest kernel changes.
We use to enforce this earlier as part of CI when `packaging` was
a standalone repo.
Add back this check as part of a github action so that the check is
performed early on instead of a CI job.
Fixes: #6210
Signed-off-by: Archana Shinde <archana.m.shinde@intel.com>
As the dragonball specific kernel is now part of the release, let's make
sure we build it as part of the kata-deploy-push action.
Fixes: #5859
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
As the dragonball specific kernel is now part of the release, let's make
sure we build it as part of the kata-deploy-test action.
Fixes: #5859
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's add the dragonball specific kernel, which takes advantage of
upcall, as part of the release tarball, so it can be used from the
release tarball / kata-deploy.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This is to enable quay.io/confidential-containers/runtime-payload for
s390x on top of amd64.
Fixes: #5894
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
e1f075dc60 reworked the action so the
shim-v2 was split out of the matrix build. With that done I ended up
not realising I'd need to log into the quay.io as one step of the
build-asset-cc-shim-v2 job.
Fixes: #5885
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
The ability to do a measured boot has been overlooked when releasing the
payload consumed by the Confidential Containers project, and this
happened as we depend, at the shim-v2 build time, of a `root_hash_*.txt`
generated in the `tools/osbuilder/` directory, which is then used to add
a specific parameter to the `kernel_params` in the Kata Containers
configuration files.
With everything said above, the best way we can ensure this is done is
by saving those files during the rootfs build, download them during the
shim-v2 build (which *must* happen only after the rootfs builds happen),
and correctly use them there.
Fixes: #5847
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This is to differentiate an artifact name between amd64 and s390x and add a
virtiofsd target for s390x.
Fixes: #5851
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
Call cargo in root's HOME may lead to permission error, should
call cargo installed in user's HOME/PATH.
Fixes: #5813
Signed-off-by: Bin Liu <bin@hyper.sh>
Setup the snapcraft environment manually as the action we had been using
for this does not appear to be actively maintained currently.
Related to this, switch to specifying the snapcraft store credentials
using the `SNAPCRAFT_STORE_CREDENTIALS` secret. This unbreaks
`snapcraft upload`, which Canonical appear to have broken by removing
the previous facility.
Fixes: #5772.
Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
So that we get the latest language fixes.
There is little use to maitain compiler backward compatibility.
Let's just set the default golang version to the latest 1.19.2.
Fixes: #5494
Signed-off-by: Peng Tao <bergwolf@hyper.sh>
Although introducing an awful amount of code duplication, let's
parallelise the static checks in order to reduce its time and the space
used in the VMs running those.
While I understand there may be ways to make the whole setup less
repetitive and error prone, I'm taking the approach of:
* Make it work
* Make it right
* Make it fast
So, it's clear that I'm only attempting to make it work, and I'd
appreciate community help in order to improve the situation here. But,
for now, this is a stopgap solution.
JFYI, the time needed for run the tests on the `main` branch went down
from ~110 minutes to ~60 minutes. Plus, we're not running those on a
single VM anymore, which decreases the change to hit the space limit.
Reference: https://github.com/kata-containers/kata-containers/actions/runs/3393468605/jobs/5640842041
Ideally, each one of the following tests should be also split into
smaller tests, each test for one component, for instance.
* static-checks
* compiler-checks
* unit-tests
* unit-tests-as-root
Fixes: #5585
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
(cherry picked from commit 40d514aa2c)
Although introducing an awful amount of code duplication, let's
parallelise the static checks in order to reduce its time and the space
used in the VMs running those.
While I understand there may be ways to make the whole setup less
repetitive and error prone, I'm taking the approach of:
* Make it work
* Make it right
* Make it fast
So, it's clear that I'm only attempting to make it work, and I'd
appreciate community help in order to improve the situation here. But,
for now, this is a stopgap solution.
JFYI, the time needed for run the tests on the `main` branch went down
from ~110 minutes to ~60 minutes. Plus, we're not running those on a
single VM anymore, which decreases the change to hit the space limit.
Reference: https://github.com/kata-containers/kata-containers/actions/runs/3393468605/jobs/5640842041
Ideally, each one of the following tests should be also split into
smaller tests, each test for one component, for instance.
* static-checks
* compiler-checks
* unit-tests
* unit-tests-as-root
Fixes: #5585
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
The specific TDX image relies on having EAA KBC, instead of using the
default `offline_fs_kbc`.
This image is, with this commit, built and distributed, but not yet used
by TDX specific configurations, which will be done in a follow-up
commit.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
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>
