This PR removes unused the publish kata image script which
was used on kata 1.x when we had OBS packages which are not
longer used on kata 2.x
Fixes#4496
Signed-off-by: Gabriela Cervantes <gabriela.cervantes.tellez@intel.com>
This script is responsible for generating a tarball with all the rust
vendored code that is needed for fully building kata-containers on a
disconnected environment.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
During the release of 2.4.0-rc0 @egernst noticed an incositency in the
way we handle release tags, as release candidates are being taken as
"stable" releases, while both the kata-deploy tests and the release
action consider this as "latest".
Ideally we should have our own tag for "release candidate", but that's
something that could and should be discussed more extensively outside of
the scope of this quick fix.
For now, let's align the code generating the PR for bumping the release
with what we already do as part of the release action and kata-deploy
test, and tag "-rc" as latest, regardless of which branch it's coming
from.
Fixes: #3847
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Escape (with backslash) backticks (`) to prevent them from being
evaluated by the shell.
Fixes: #3487
Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>
All repos we release (https://github.com/kata-containers/kata-containers
and https://github.com/kata-containers/tests) have a VERSION file.
Keeping a check for it, although useful for a new repo, just complicates
the use-case we currently deal with.
While here, let's also anchor the '#' and potentially exclude blank
lines, following James' suggestion.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
`grep`ing by a specific output, in a specific language, is quite fragile
and could easily break `hub`. For now, let's work this around following
James' suggestion of setting `LC_ALL=C LANG=C` when calling `hub`.
> **Note**: I don't think we should invest much time on fixing `hub`
> usage, as it'll be soon replaced by `gh`, see:
> https://github.com/kata-containers/kata-containers/issues/3083
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
When branching the "stable-x.y" branch, we need to do some quite
specific changes to kata-deploy / kata-cleanup files, such as:
* changing the tags from "latest" to "stable-x.y".
* removing the kata-deploy / kata-cleanup stable files.
However, after the branching is done, we need to get the `main` repo to
its original state, with the kata-deploy / kata-cleanup using the
"latest" tag, and with the stable files present there, and this commit
ensures that, during the release process, a new PR is automatically
created with these changes.
Fixes: #3069
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Rather than doing the kata-deploy changes as part of the release bump
commit, let's split those on its own changes, as it will both make the
life of the reviewer less confusing and also allows us to start
preparing the field for a possible automated revert of these changes,
whenever it becomes needed.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Similarly to what was done for the yaml files, let's use a var for
representing the registry where our images will be pushed to and avoid
repetition and too long lines.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Instead of always writing the full path of some files, let's just create
some vars and avoid both repetition (which is quite error prone) and too
long lines (which makes the file not so easy to read).
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
We can simplify the code a little bit, as at least now we group common
operationr together. Hopefully this will improve the maintainability
and the readability of the code.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
The comments were mentioning kata-deploy-base files while it really
should mention kata-deploy-stable files.
While here, I've also added a missing '"' to one of the tags.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
The `kata-agent` binaries inside the Kata Containers images provided
with release are statically linked with the GNU LGPL-2.1 licensed
libseccomp library by default.
Therefore, we attach the complete source code of the libseccomp
to the release page in order to comply with the LGPL-2.1 (6(a)).
In addition, we add the description about the libseccomp license
to the release page.
Fixes: #2922
Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>
This commit will add containerd to versions.yaml.
Please at now there are both containerd and cri-containerd
in the versions.yaml.
After updating of kata-containers/tests repo, the cri-containerd
should be removed.
Fixes: #2791
Signed-off-by: bin <bin@hyper.sh>
Let's teach our `update-repository-version.sh` script to properly update
the kata-deploy tags on both kata-deploy and kata-cleanup yaml files.
The 3 scenarios that we're dealing with, based on which branch we're
targetting, are:
```
1) [main] ------> [main] NO-OP
"alpha0" "alpha1"
+----------------+----------------+
| from | to |
-----------------+----------------+----------------+
kata-deploy | "latest" | "latest" |
-----------------+----------------+----------------+
kata-deploy-base | "stable | "stable" |
-----------------+----------------+----------------+
2) [main] ------> [stable] Update kata-deploy and
"alpha2" "rc0" get rid of kata-deploy-base
+----------------+----------------+
| from | to |
-----------------+----------------+----------------+
kata-deploy | "latest" | "rc0" |
-----------------+----------------+----------------+
kata-deploy-base | "stable" | REMOVED |
-----------------+----------------+----------------+
3) [stable] ------> [stable] Update kata-deploy
"x.y.z" "x.y.(z+1)"
+----------------+----------------+
| from | to |
-----------------+----------------+----------------+
kata-deploy | "x.y.z" | "x.y.(z+1)" |
-----------------+----------------+----------------+
kata-deploy-base | NON-EXISTENT | NON-EXISTENT |
-----------------+----------------+----------------+
```
And we can easily cover those 3 cases only with the information about
the "${target_branch}" and the "${new_version}", where:
* case 1) if "${target_branch}" is "main" *and* "${new_version}"
contains "alpha", do nothing
* case 2) if "${target_branch}" is "main" *and* "${new_version}"
contains "rc":
* change the kata-deploy & kata-cleanup tags from "latest" to
"${new_version}".
* delete the kata-deploy-stable & kata-cleanup-stable files.
* case 3) if the "${target_branch}" contains "stable":
* change the kata-deploy & kata-cleanup tags from "${current_version}"
to "${new_version}".
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Removed all TOCs now that GitHub auto-generates them.
Also updated the documentation requirements doc removing the requirement
to add a TOC.
Fixes: #2022.
Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
Update kata-deploy-binaries.sh cli options.
Add options to allow ask build a tarball for a specific asset.
It will help developers build a specific component and update
a kata-deploy installation. Also build each asset independetly
can help to create cache tarballs per asset in the future.
e.g. Build a tarball with shimv2.
```
./kata-deploy-binaries.sh --build=shim-v2
```
Additionally, the script path is moved to a new directory
as not only will work for releases.
Signed-off-by: Carlos Venegas <jos.c.venegas.munoz@intel.com>
Let's teach `update-repository-version.sh` to automatically bump the
version of the kata-deploy images to be used within that release, when
running against the `kata-containers` repo.
Fixes: #1665
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
This doesn't make much difference for the automated process we have in
place, but makes a whole lot of difference for those trying to have the
binaries deployed locally.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
There's no runtime repo anymore, let's avoid making a reference to it,
which may end up confusing people reading the Release-Process file.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
There's no reason to ship qemu & qemu-virtiofs when the former already
includes vitiofs support (and that's the default for 2.x deployments).
In case we will enable experimental qemu DAX support, we should add a
new target, a "qemu-experimental" target, as Carlos has been working on.
Fixes: #1424
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
The docker script has been removed as part of
62cbaf4de4, but references to it were left
behind in the artifact-list.sh, release/kata-deploy-binaries.sh, and
kata-deploy/Dockerfile.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Update all tools/packaging scripts to prefer the new options over the
old ones (e.g. `--config` instead of `--kata-config`).
Signed-off-by: Daniel Knittl-Frank <knittl89+git@googlemail.com>
2.0 Packaging runtime-release-notes.sh script is using 1.x Packaging
kernel urls. Fix these urls to 2.0 branch Packaging urls.
Fixes: #829
Signed-off-by: Ychau Wang <wangyongchao.bj@inspur.com>
We should just download the official static build binary instead of
trying to build on our own.
Fixes: #760
Signed-off-by: Peng Tao <bergwolf@hyper.sh>
Since we always build musl kata-agent, there is no need to build
it inside a musl container. We can just build on the host and then
copy the binary to the target rootfs.
There are still a lot to clean up and it should be made so for ALL
target distros instead of just alpine. But this is at least working
for alpine first.
Signed-off-by: Peng Tao <bergwolf@hyper.sh>
