In order to check that we don't accidentally overwrite
release artifacts, we should add a check if the release
name already exists and bail if it does.
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
So users can simply download the chart and use it accordingly without
the need to download the full repo.
Signed-off-by: Fabiano Fidêncio <fabiano@fidencio.org>
This reverts commit e9710332e7, as there
are now 2 arm64-builders (to be expanded to 4 really soon).
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This reverts commit c5dad991ce, as there
are now 2 arm64-builders (to be expanded to 4 really soon).
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's remove what we commented out, as publish manifest complains:
```
Created manifest list quay.io/kata-containers/kata-deploy-ci:kata-containers-latest
./tools/packaging/release/release.sh: line 146: --amend: command not found
```
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
It's been a reasonable time that we're not able to even build arm64
artefacts.
For now I am removing the builds as it doesn't make sense to keep
running failing builds, and those can be re-enabled once we have arm64
machines plugged in that can be used for building the stuff, and
maintainers for those machines.
The `arm-jetson-xavier-nx-01` is also being removed from the runners.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Since yq frequently updates, let's upgrade to a version from February to
bypass potential issues with versions 4.41-4.43 for now. We can always
upgrade to the newest version if necessary.
Fixes#9354
Depends-on:github.com/kata-containers/tests#5818
Signed-off-by: Beraldo Leal <bleal@redhat.com>
The automated release workflow starts with the creation of the release in
GitHub. This is followed by the build and upload of the various artifacts,
which can be very long (like hours). During this period, the release appears
to be fully available in https://github.com/kata-containers/kata-containers/
even though it lacks all the artifacts. This might be confusing for users
or automation consuming the release.
Create the release as draft and clear the draft flag when all jobs are
done. This ensure that the release will only be tagged and made public
when it is fully usable.
If some job fails because of network timeout or any other transient
error, the correct action is to restart the failed jobs until they
eventually all succeed. This is by far the quicker path to complete
the release process.
If the workflow is *canceled* for some reason, the draft release is left
behind. A new run of the workflow will create a brand new draft release
with the same name (not an issue with GitHub). The draft release from
the previous run should be manually deleted. This step won't be automated
as it looks safer to leave the decision to a human.
[1] https://github.com/kata-containers/kata-containers/releasesFixes#9064 - part VI
Signed-off-by: Greg Kurz <groug@kaod.org>
Now that the version is an invariant for the entire workflow, it
isn't required to obtain it with an environment variable. Just
rely on the content of the `VERSION` file like other actions.
Fixes#9064 - part VI
Signed-off-by: Greg Kurz <groug@kaod.org>
This reverts commit 0fa59ff94b, as now
we'll be able to use the `--generate-notes`, hopefully, without blowing
the allowed limit.
Fixes: #9064 - part VI
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This release is a special case, as we've slacked for 6 months and the
release content is way too long ... long enough to exceed the allowed
limit for the release notes.
With this in mind we'll just remove the `--generate-notes` for now, and
then revert this commit as soon as the release is out, as releases
should be happening every month and, ideally, we won't reach this
situation never ever again.
Fixes: #9064 - part V
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This is done in order to avoid having to push a commit to the main
branch, which is against the defined rules on GitHub.
By doing this, we need to educate ourselves to always bump the VERSION
file as soon as a release is cut out.
As a side effect of this change, we can drop the release-major and
release-minor workflows, as those are not needed anymore.
Fixes: #9064 - part IV
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
We're trying to keep just the bare minimum info, as we really would like
to not have the list of commits, and mainly the list of new
contributors, trucated from the release notes.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
We need to ensure the release type is passed down to workflows,
otherwise we'll fail to get the correct release version for tagging the
daemonset images.
Fixes: #9064 - part III
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This is not needed anymore as we can run the tests from any branch, and
we can patch this locally before doing a test.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
I'm getting here the most relevant parts of what we had as part of the
release-notes.sh script. As the script will not be used anymore, it's
been removed.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
For some reason we need to force its installation in the GOPATH,
otherwise yq is not found.
Ideally we should switch to a packaged version of yq, but that's a topic
for another series.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This is utterly counter intuitive, but if we change a file during the
GitHub Action, the checkout done for the next workflow won't have that
file updated, but rather the branch on its original state when the
workflow was created.
This makes us safe to always "calculate" the next release version from
the VERSION file at the time the workflow was triggered.
This requires us to have the release type exported for the whole
workflow.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
We missed doing this as part of
50011e89a0, but we also need to check for:
* RELEASE_VERSION
* GH_TOKEN
* ARCHITECTURE
* KATA_STATIC_TARBALL
While here, let's fix a ARCHITECURE -> ARCHITECTURE typo.
Fixes: #9064 -- part II
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This commit should be merged as it's now, then we trigger a test
release, fix whatever has to be fixed, and drop it as soon as we know
our workflows are working as expected.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This function returns the version of the next release (the one about to
be cut), and it'll be used as part of our new workflow that will take
care of the release.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's add a function that will be responsible for bumping the project's
version in the VERSION file, and push it to the branch as part of the
release process that will be introduced.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This is a helper function that will be used to create a new release as
part of our release process workflow (which will still be modified).
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
As the name of the function says, it's responsible for uploading the
libseccomp source tarballs as par of our release process.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
As hinted by the name of the function, this is used to generate and
upload the vendored code we have as its own tarball.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
As the name says, this function will be used to upload the versions.yaml
file during a given release process of the project.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This function, as it names says, will be used to upload the
kata-static.tar.xz tarballs generated during the release process.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
This function, as it names says, will be used to publish multiarch
manifests for the Kata Containers CI and Kata Containers releases.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
For now this script does nothing, but we're introducing it in order to
redduce the diffs for the next commits in this series.
My intention is to have as much as possible related to the release as
part of this helper script, and it'll be populated function by function
while replacing content that's "hard coded" (and duplicated) on
different GitHub actions.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>