| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately, git submodules break in all sorts of ways:
- Various github workflows (dependabot, github pages) try to do a shallow
clone of git submodules which does not work at all when the git repository
is hosted on pagure (https://pagure.io/pagure/issue/5453,
https://github.com/dependabot/dependabot-core/issues/9391).
- If the git forge hosting the git repository uses SHA256, then it breaks our
usage of it as a submodule as SHA256 repositories cannot be used as submodules
in SHA1 repositories (src.opensuse.org moved to SHA256 which broke our usage of
opensuse's systemd spec as a submodule).
- git submodules completely break usage of git worktrees.
- ...
Let's avoid all these issues by just doing our own home grown implementation of
git submodules. We lose the automatic dependabot updates this way but since dependabot
fails to run more often that not with submodules we don't really lose anything.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By always cloning the latest branch commit, we can't bisect properly
using mkosi as when bisecting wildly different packaging sources will
be used compared to when the commit was merged. By using submodules, we
track individual commits which means when bisecting the same packaging
sources will be used.
We use git submodules as dependabot has support for automatically making
PRs to update git submodules. This commit also includes the necessary
dependabot configuration to enable this.
We make ubuntu/debian use the same submodule instead of adding the debian
packaging sources twice by introducing a new $PKG_SUBDIR environment variable
and using it instead of $DISTRIBUTION.
|
| |
|
|
|
| |
Apparently some actions like CodeQL are released a few times a week so let's
just update them once a month in one fell swoop.
|
| |
|
|
|
|
|
| |
It's like CIFuzz but unlike CIFuzz it's compatible with forks and
it should make it possible to run the fuzzers to make sure that
patches backported to them are backported correctly without introducing
new bugs and regressions.
|
| | |
|
| |
|
|
|
|
|
|
| |
Apparently some dependencies get updated much more often
than I would have exepected.
It can always be triggered manually at https://github.com/systemd/systemd/network/dependencies
if there are any urgent updates
|
| | |
|
| |
|
|
|
|
|
|
| |
Apparently version updates aren't always disabled on old forks,
which leads to new PRs opened there. To somewhat mitigate the
issue let's limit the number of PRs Dependabot can create.
It was reported in https://github.com/yuwata/systemd/pull/2#issuecomment-967737195
|
|
|
Turns out GHActions where `pull_request_target` is used are capable
of pwning repositories: https://securitylab.github.com/research/github-actions-preventing-pwn-requests/
labeler doesn't check out the source code or build anything so
it's safe in its current form but to avoid surprises let's just pin
it to the latest version. It's annoying to manage dependencies like this
manually so additionally dependabot.yml is introduced to make it
easier to keep GHActions up to date more or less automatically:
https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/keeping-your-actions-up-to-date-with-dependabot
|
