IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
`github.event.issue.pull_request` is an object, not a boolean.
This is the root cause of why the step that is supposed to remove labels
is always skipped. Having this condition in place is not necessary since
the workflow is run on the `pull_request_target` event.
(The one case that is left unchanged is '< <(subcommand)'.)
This way, the style with no gap was already dominant. This way, the reader
immediately knows that ' < ' is a comparison operator and ' << ' is a shift.
In a few cases, replace custom EOF replacement by just EOF. There is no point
in using someting like "_EOL" unless "EOF" appears in the text.
Due to the limitation of `GITHUB_TOKEN` when running workflows from forks,
it's required to split the `development_freeze` workflow in two.
* First workflow will run on the `pull_request` trigger and save the PR
number in the artifact. This workflow is running with read-only permissions
on `GITHUB_TOKEN`.
* Second workflow will get triggered on `workflow_run`. It will be run
directly in the `systemd/systemd` context and can get permission to be
able to create comments on PR.
GITHUB_TOKEN limitations:
* https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token
GitHub Security Labs Article - How to correctly and safely overcome GITHUB_TOKEN limitations:
* https://securitylab.github.com/research/github-actions-preventing-pwn-requests/
This gives us some nice test coverage for secure boot enrolling and the
stub secure boot workound. The authenticated EFI variables are already
created by mkosi, all we need to do is request secure boot to be used.
It's still useful to test the EFI handover logic in systemd-boot.
We use a mkosi.prepare script to install a newer python and update
the system to use it.
We also add the necessary deps for ukify to the mkosi configs.
CentOS Stream 8 is dropped from CI because its python version is too
old (3.6) to be able to run ukify.
Let's make sure we're testing with the latest changes in mkosi. This
includes both the switch to systemd-repart and ukify, making sure we
get extra testing coverage for those components.
This also drops options from the centos config that have been removed
in the newer mkosi.
For some reason idmapping runs into some issues so we disable it for
now.
Meson started warning when 'setup' is not used:
WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated.
Also add more quoting in output to make the message clearer.
- Mention "/please-review" in the contributing guide
- Remove "needs-rebase" on push
- Don't add "please-review" if a green label is set
- Don't add please-review label to draft PRs
- Add please-review when a PR moves out of draft
When a pull request is opened/updated, add "please-review" and
remove a few other labels.
When a comment is made with /please-review on a PR. Add the
"please-review" label to the PR.
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-including-and-excluding-paths
> If you define a path with the ! character, you must also define at least one
> path without the ! character. If you only want to exclude paths, use
> paths-ignore instead.
>
> The order that you define patterns matters:
> A matching negative pattern (prefixed with !) after a positive match will
> exclude the path.
> A matching positive pattern after a negative match will include the path
> again.
Even if some of the exluded paths *could* impact the build, generally it's a
waste of time to do mkosi builds on them. Let's skip to releave the builders a
bit.
GitHub Action `devel-freezer` helps with development freeze notifications
during the RC phase. It will create comments using predefined messages on
newly created and updated PRs when the RC tag has been released.
Also, it will update comments once a new major version has been released.
Documentation available at: https://github.com/redhat-plumbers-in-action/devel-freezer
In the Xen case, it's the hypervisor which manages kexec. We thus
have to ask it whether a kernel is loaded, instead of relying on
/sys/kernel/kexec_loaded.
Also, unify the string quotation a bit and drop one unnecessary
expression syntax (as everything in `if` statements is automatically
evaluated as an expression).
* chore: enable scorecard action
* chore: add badge to the README file
* chore: enable on config file update
* chore: update scorecard to 2.0.4
* chore: run scorecard on PR at main branch
* chore: add condition to publish_result key
* chore: skip upload to code scanning if PR
* chore: only runs scorecard in the main repo
Resolves: #25042
