We would like to switch to exclusively using Packit for building and
testing pull requests, so we are retiring this GitHub Action workflow.
We will want to configure Packit to check that DNF5 compiles with both
GCC and clang, like the Package Build action did.
In order to fully disable the action, this commit must be applied on
each branch in the upstream DNF5 repository. Otherwise, the action might
be triggered by a pull request to some stale branch.
This workflow runs periodically once a day, but it's also possible to
run it ad hoc from the GitHub web interface. It consists of the
following steps:
- Clone the dnf5 repository.
- Build fresh *.pot files using the gettext-potfiles CMake target.
- Clone the dnf5-l10n synchronization repository.
- Each *.pot file represents a Weblate component. For each file, a
directory is created (if it doesn't already exist), the *.pot file is
copied there, and a PATH file with the actual location of the component
in the dnf5 source tree is created.
- The new version is then directly pushed into the dnf5-l10n repository.
The dnf5-l10n repository serves the purpose of reducing commit traffic
with new translations coming from Weblate. This approach helps us
maintain a cleaner dnf5 Git history. New translations from Weblate will
be pulled automatically as part of the prepare-release GitHub workflow.
Thanks to cockpit team for inspiration!
This is needed because since rpm-software-management/dnf#1937
new dnf-data (in dnf-nightly) requires `/etc/dnf/dnf.conf` but in rawhide
and dnf-nightly nothing provides that. It is provided by new libdnf5
currently only present in dnf5-unstable.
Currently the workaround for Fedora 36 clang-format issue
(https://github.com/llvm/llvm-project/issues/55260) is in the
dnf-ci-host container (see
23e4400f4f
for details).
This PR makes the workaround local to "Clang Format" job. It enables us
to move "DNF Integration Tests" job back to the latest Fedora.
More details: https://github.com/actions/checkout/issues/766
This is needed because we run in ./ (we do not cd into any directory
created by our current user), this is problematic because the working
directory is owned by the github actions runner user not our current
container user and git doesn't allow that since the mentioned CVE.
We have to explicitly state it is a safe directory.
Evan Goode