The baselayout ebuild file calls systemd-tmpfiles but despite that
the systemd ebuild file depends on libidn2 through a use flag, it was
not built early enough.
Ensure that libidn2 is built before baselayout wants to use it.
The metadata/md5-cache folder is machine-generated based on the
other files in the repository. It causes merge conflicts when at
one time they were not regernated in a commit and then later a
commit does it and includes cache changes which are incompatible
with later or newer states.
Remove the folder as it is not necessary to have it and was removed
in upstream Gentoo, too.
The new main branch is the only branch that should get new software
updates with the exception of the maintenance branches that get kernel
updates.
Only target the main branch with GitHub Actions until we add discovery
for all active channel maintenance branches.
So far Github actions have not changed existing `COMMIT_ID` variable in
runc ebuilds. As a result, the result PRs have correct versions with wrong
commit hashes.
We need to replace `COMMIT_ID` with one that matches with the new version.
To do that, clone the repo completely, since it is not possible to get
the commit hash by running `git rev-parse` on a shallow cloned repo.
Parse commit from a tag with an original version with `-` as its
delimiter, e.g. `v1.0.0-rc91`, because a transformed
tag like `v1.0.0_rc91` does not exist in the upstream repo.
We need to update rust versions also in multiple files in profiles,
e.g. `package.accept_keywords`. Otherwise `emerge rust` will fail,
due to mismatches between rust versions, in profiles and the actual
ebuilds.
docker-runc ebuild has lines of runc versions with not only underscore
(`_`) but also hyphen (`-`). So when we replace the runc version, we
need to also care about versions with hyphen, for example, `1.0.0-rc10`.
`exit` command will simply fail the whole script, so it would not be
possible to check for status of `checkout_branches`. Instead, we need to
use `return` for the error checks.
In case the target branch already exists, `checkout_branch()` needs to
simply `exit 0`, so the subsequent steps could be skipped.
In that case, it has to set `UPDATE_NEEDED` to 0, so the Github action
could avoiding creating another PR.
It resolves occasional issues that happen when subsequent PRs overwrite
existing open PRs made on the very same version. It would be no problem
if there was no change in the PR. However, if there was any manual
change in the previous open PR, the change will be simply overwritten.
That would be very unfortunate.
When checking out into a branch name, append `-${CHANNEL}` to the name,
so the branch can be distinguished from each other. To do that, make
every Github actions yaml file pass in its corresponding `CHANNEL`
variable.
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.
