We previously ran tasks-container-update and cockpit-lib-update at the
same time, which sometimes collides. Move it to the night between Sunday
and Monday instead, so that we have the updates ready for us to inspect
when we start our week.
Github usually updates their actions once a while and then warns about a
node env getting deprecated in runs. Which is not super easily spotted
by a developer until it's too late, so let's like npm let dependabot
handle updating.
So far the daily updates tend to run in our mornings between 7:00 and
8:00, which blocks our CI for a long time, and thus collides with
developers sending PRs. Move them to the evening instead, when they can
use the quiet bots time.
Also reduce the number of parallel PRs from 5 to 3. Parallel ones always
need to be rebased, and thus are very expensive. We still want to be
able to have a complicated PatternFly PR open for several days without
blocking other updates.
This action works similar to the npm-update workflow, it creates a PR
every Thursday (usually after the Cockpit release) to update the
COCKPIT_REPO_COMMIT to the latest version.
This gets rid of our "release" environment with high-profile secrets,
and the cockpituous/release infra.
The upstream release uses our shared
https://github.com/cockpit-project/action-release/ action.
This partitions secrets and limits their potential exposure/leakage.
This environment can be created with github-upload-action-secrets in [1].
[1] https://github.com/cockpit-project/bots/pull/2164
It currently reacts to /livetest comments on PRs and builds cockpit from
the PR's checkout. Then serves it on logs.cockpit-project.org on a port
specified on a follow-up comment to the /livetest.
Cockpit developers can now utilize this workflow to review a PR without
having to pull and compile the code locally.
GitHub's base VMs don't automatically refresh package indexes, so it can
happen that one of the package dependencies get out of date and are not
available on the mirrors any more.
Run `apt update` first to ensure that the workflow installs the latest
packages.
With [1] the release container moved from dockerhub to GitHub's
container registry, as we both build and use it from GitHub. This avoids
running into docker.io pull limits.
[1] https://github.com/cockpit-project/cockpituous/pull/353Closes#398
This avoids a lot of moving parts in our infrastructure (webhook,
npm-trigger roundtrip, tasks container), works in exactly the same way
for independent third-party projects, and does not need *any* secret
other than the automatically provided GitHub token.
Let this run early every morning, roughly similar frequency as
cockpituous used to do. Also add a manual trigger, so that we get a
button to run it on demand.
Closes#384
Enter the new world of GitHub actions [1]/GitLab pipelines [2]. This
simplifies our end of the infrastructure considerably:
* No need any more to set up webhooks, all the relevant configuration
is right in the workflow file.
* Does not need any infrastructure on our side any more, and thus works
for third-party projects. They just need to set up their own secrets.
* GitHub automatically provides a temporary `GITHUB_TOKEN` with
sufficient write access to the project to publish a release, so we
don't need to carry around that secret. Thus if your project only
releases to GitHub, there is zero secrets management.
Also adjust cockpituous-release a bit (update Fedora version, fix
project name copy-pasta), point to the action workflow and necessary
secrets.
Closes#380
