Since Pico depends on PicoDeprecated, and PicoDeprecated depends on Pico, a chicken-egg-problem arises: When pushing a new tag for Pico, GitHub Actions will try to build this new release by downloading the matching version of PicoDeprecated from Packagist. Since we didn't release a new version of PicoDeprecated yet, this will fail. So we need to push PicoDeprecated's tag first. Doing so yields GitHub Actions trying to build PicoDeprecated's new release - by trying to download the matching version of Pico from Packagist, which doesn't exist yet.
Thus builds will always fail - unless you push both tags at the exact same time, and unless you send some prayers that GitHub Actions delays building until Packagist picks up the new releases. The simplest solution is not to use GitHub Actions to publish new releases, but letting the user to do it instead. With this changeset this is as simple as `make publish version=v3.0.0`. The 'deploy-release' GitHub workflow now just updates the website and is triggered by publishing the GitHub release, not the tag. This additionally allows the user to perform some manual tests before publication.
The build script now depends on GitHub CLI (`gh`), see https://cli.github.com/. You must setup authentication first (`gh auth login`).
Mimics the behaviour of the 'deploy-release' workflow, even though branch deployment doesn't depend on Pico's tests to succeed. Pull requests still use the 'test' workflow directly.
Since Travis CI was transformed into a proprietary service we didn't have a CI pipeline. This heavily refactors and simplifies the CI pipeline and uses GitHub Actions to deploy new Pico releases. You can use Pico's Makefile to build new releases locally, too. Pico's build script no longer depends on any external resources (like our `picocms/ci-tools` collection). However, this isn't true for other release deployment steps, like updating phpDoc class docs, version badge, cloc stats, etc., even though the CI scripts are mostly self-containing now.
After resolving a issue, we usually keep it open for about a week to give users some more time for feedback and further questions. This is especially true for issues with the `type: Notice`, `type: Question`, `type: Discussion` and `type: Invalid` labels. After 7 days with no interaction, [Probot](https://probot.github.io/)'s [Stale](https://probot.github.io/apps/stale/) bot (@probot-stale) adds the `info: Stale` label to the issue to ask the participants whether the issue has been resolved. If no more activity occurs, the issue will be automatically closed by @probot-stale 2 days later.
Daniel Rudolf