We do not need to specify each version from each workflow yaml file.
Make *-apply.patch scripts instead generate `$VERSION_SHORT` from the
input version value.
We do not need to specify a cork version from each Github action.
Simply detect the latest version in `setup-flatcar-sdk.sh`, before
downloading cork binary file from Github.
Also remove the env variable for cork version from each Github action.
To get containerd in sync with upstream, we need to schedule weekly
Github actions. It runs on Friday every week, only for Alpha and Edge.
Similar to those for Docker, we need to deal with torcx ebuilds as well,
as they contain containerd versions.
We do not need to run once in a day to check for updates from
ordinary packages. Most releases happen once in more than a week.
So schedule the Github actions only once in a week for most packages.
Go on Mon, Rust on Tue, Docker on Wed, Runc on Thu.
Note, we still need to check for Kernel once in a day, as Kernel
releases happen quite often.
`kernel-apply-patch.sh` cannot detect the existing kernel version,
if the version does not have a patchlevel, e.g. `5.6`. So the old
kernel version variable becomes an empty string, and the final pull
request has an empty field after the `from` string.
If the Manifest does not have a `patch-` line, try to read a `linux-`
line again, to detect the correct kernel version.
Schedule daily Github actions for creating PRs for upstream Rust releases.
The Github workflow will create pull request for `dev-lang/rust` in
`coreos-overlay`. At the same time, it will send a repository dispatch
event to `flatcar-linux/portage-stable`, to update also `virtual/rust`.
We need to send different event types to distinguish alpha from edge.
When setting up a Flatcar SDK from scratch, we need to also set up
correct configs in `/etc/portage/make.conf`. For example we need to
set `PORTDIR=/mnt/host/source/src/third_party/portage-stable` instead
of the default Gentoo configs like `PORTDIR=/var/gentoo/repos/gentoo`.
Otherwise `update_metadata` will fail in some cases, because portage
cannot find the correct location of portage-stable.
Before starting to apply patches inside `coreos-overlay`, we need to
check out base branches, also for `scripts` and `portage-stable`.
Otherwise, in case of Beta, Alpha, or Edge, `ebuild` commands could
fail due to mismatch of ebuild files across multiple repos like
`coreos-overlay` and `portage-stable`.
Schedule daily Github actions for upstream runc releases, just like
Docker.
In this case, we also need to update multiple repos like
`app-emulation/docker`, `app-emulation/containerd`, `app-torcx/docker`, etc.
Schedule daily Github actions to get upstream Docker releases,
for Alpha and Edge.
We need to change more files, as Docker version is used by torcx
as well as docker-runc.
We need to set up coreos profiles under `/etc/portage/repos.conf`, to be
able to run any package-related actions like `emerge` or `egencache`.
Also change permissions for directories, so portage actions could write
files.
To reduce running time of git clone, we should avoid a full git clone
of the linux kernel repo. Instead, we shallow clone the repo, and
parse tags list by running `git ls-remote`.
If the current Flatcar release is already the latest Kernel, we should
simply exit with 0, without giving a failure status 1. The `exit 1`
would the otherwise result in a failure of the entire Github actions.
This commit add 2 different Github actions that run once in a day,
one for Alpha, Kernel 4.19, and the other for Edge, Kernel 5.5.
Because of limitations of Github Actions, i.e. create-pull-request
actions, we cannot combine the two actions into one.
Also we need to create a patch and apply it to the top source directory,
since the create-pull-request action requires the changes in the top
directory.
Although we are not updating flatcar-master branch, (only Alpha and
Edge) the Github actions files need to be merged to flatcar-master,
because Github actions can only schedule cron jobs from the default
branch, flatcar-master.
The caching git web view which was used as source location is not
reliable because the cache can be corrupt, the gzip compression of the
snapshot can change, and the cache is produced by the web server which
is not there to give high security guarantees. We experienced cache
corruption.
Switch to the recommended mirror under
https://mirrors.edge.kernel.org/pub/linux/kernel/firmware/
which also hosts signatures and not having the downsides mentioned
above. This is a downstream change until upstream Gentoo changes the
location.
