Don't use master-test branch from ci/workflows for
test-packaging.yaml, because it might mo away. Use master instead.
Signed-off-by: Jan Lindemann <jan@janware.com>
Add enable-email-notifications: true. This seems to be needed for sending
information about failed runs. Apparently it doesn't make it difference if I
add it to ci/workflows/.github/workflows/test-packaging.yaml.
Signed-off-by: Jan Lindemann <jan@janware.com>
In another attempt at making CI workflow naming more concise:
- Rename standard-tests.yaml to ci.yaml
Currently the contents of this file covers everything CI-related
that happens in the context workflows, so for the time being,
naming it ci.yaml is just fitting. And it's going to be shorter
in commit message summaries. Should a real need arise, we can
always split the file up again.
- Shorten names again, otherwise they don't fit into Forgejo's
check-mark-popup. That should be self-explanatory in context:
name:
Default CI -> CI
jobs.CI.name:
Packaging test - All supported platforms -> Packaging test
Signed-off-by: Jan Lindemann <jan@janware.com>
This commit reorganizes build-package.yaml in several ways:
- Follow name change of the called workflow
The reusable workflow used by build-package.yaml changed name and
location, and this commit follows the move. It was located at
ci/action-build-package before and has moved to ci/workflows,
because what it provides is semantically more of a workflow than
an action.
- Limit CI runs
The commit also adds safeguards against too many CI runs. It
limits them to PR events opened, re-opened or pushed-to, and to
push events hitting branches master, main and release.
- Rename workflow itself to standard-tests.yaml
That name reflects better what it represents: The entry point to
janware's standard set of CI tests. All of them happen to run in
the context of building and packaging at this point, but that
might not be the only standard test this repo chooses to
subscribe to in the future, and if so, they will be better off in
one file with defined order, so give that file a better umbrella
name.
Signed-off-by: Jan Lindemann <jan@janware.com>
Forgejo versions before 15 didn't support workflow expansion, and
"runs-on" was necessary in callers of reusable workflows. janware.com
now runs Forgejo 15.x, and the requirement is gone, so remove the config
option.
Quoting from https://forgejo.org/docs/latest/user/actions/reference/
runs-on is typically a required field. However, if a job defines
jobs.<job_id>.uses in order to reference a reusable workflow, then it
is optional. See jobs.<job_id>.uses for more information on this
behaviour.
[...]
It is recommended that jobs.<job_id>.runs-on is omitted when using
uses, as this will allow Forgejo to perform workflow expansion.
Workflow expansion results in the target workflow’s jobs appearing in
the UI as separate jobs. This provides an easier to understand
experience for accessing the logs of each job, and permits the jobs to
run on separate runners with their own runs-on fields.
Signed-off-by: Jan Lindemann <jan@janware.com>
