The new "latest" aka v1.51.1 started throwing unused errors during runs,
blocking all the other tests, to quickly unblock that until a proper
fix/rewrite is found, pin the version to the previous one.
Signed-off-by: Antonio Murdaca <antoniomurdaca@gmail.com>
Fedora 35 support was dropped, so we can update to a newer Go.
Stable RHEL 8 and 9 and Fedora 36 ships Go 1.18, so let's switch to it.
"//go:build" directives are now apparently enforced by go fmt, so that's why
there were added.
Also, all the github actions were adjusted to use Go 1.18.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Fedora 35 is going EOL on Tue 2022-12-13. At the time of writing this commit
message, that's the next day. As we do releases on Wednesdays, the next
release will never find its way to F35 and thus, there's no point in keeping
support for it.
Let's delete everything that relates to Fedora 35. If there's something that
cannot be deleted (e.g. CI containers based on F35), let's upgrade it to F37.
TestCrossArchDepsolve now uses CentOS Stream 8 because RHEL 8.4 cannot read
F37 repository metadata. This is a similar issue to
https://bugzilla.redhat.com/show_bug.cgi?id=2004853 . Basically, newer
repositories can be only read by libmodulemd >= 2.11.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Github actions have a peculiar behaviour: The "job root" directory is owned
by user with ID 1001 whereas many containers (like the Fedora one) run as root
by default. This causes git to freak out because repositories owned by
different users aren't considered safe anymore and must be explicitly allow-
listed.
This becomes a problem when we switch to Go 1.18 because it stamps build with
Git information which fails because the repository technically isn't safe.
Let's fix this by marking the repository as a safe one.
Note that the actions/checkout action has a set-safe-directory feature, but
this one is not permanent. After the action is done, the setting is removed.
See https://github.com/actions/checkout/pull/762
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
This prepares the usage of the `internal/container` from composer
directly, as opposed to the existing use in the worker. Said pkg
uses the `containers/image/v5`, which uses `proglottis/gpgme` and
the latter needs the gpgme C library. We therefore install it and
its dependencies.
It was failing on:
vendor/github.com/proglottis/gpgme/data.go:4:11: fatal error: gpgme.h: No such file or directory
Let's install this package before running the check, I verified that this
fix works locally.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Add a new generic container registry client via a new `container`
package. Use this to create a command line utility as well as a
new upload target for container registries.
The code uses the github.com/containers/* project and packages to
interact with container registires that is also used by skopeo,
podman et al. One if the dependencies is `proglottis/gpgme` that
is using cgo to bind libgpgme, so we have to add the corresponding
devel package to the BuildRequires as well as installing it on CI.
Checks will follow later via an integration test.
Adjust the timer for our automated releases to trigger the workflow at
8 UTC. This corresponds to 10am in most of our team's timezone and to
the reminder event in our team calendar.
Run unit tests in GitHub workflows in a Fedora container to enable the
dnf-json tests. Run the tests alone with the `force-dnf` flag to make
sure the tests pass and are not skipped.
Install Go using dnf instead of the GH action. The action seems to
cause issues with the $PATH.
Use the registry.fedoraproject.org container for both unit tests and
pylint on dnf-json.
Requires some reordering of the steps in each workflow and the addition
of `git-core` as a dependency.
Using Fedora 35 instead of latest because of changes in the go build
tool: The new -buildvcs flag causes issues on GitHub actions.
Fedora 36 ships pylint 2.13 that newly reports:
dnf-json:436:20: E0601: Using variable 'cache_state' before assignment (used-before-assignment)
As dnf-json is pending a big rewrite
(https://github.com/osbuild/osbuild-composer/pull/2537),
I decided to pin fedora to 35 and let the other PR decide how to proceed in
order to prevent any conflicts.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
We're counting the even and odd weeks since the Unix epoch, so this
doesn't match the odd/even calendar weeks. Consequently let's switch to
odd weeks for composer.
Instead of a human pushing a tag with the release notes let a bot do the
work.
The bot is part of our composite action in osbuild/release-action on the
create-tag branch. It calculates the next subsequent release version and
creates a tag based on pull request titles associated with the changes
since the last release.
Finally the tag is pushed to the repository.
Unfortunately GH Actions don't allow for reliably fortnightly schedules,
so we do an additional check that determines if this is an even or an
odd week. This will help with correctly scheduling alternating osbuild
and osbuild-composer releases.
Previous implementation added single quotes to the git command which
made it not trigger the Gitlab CI at all. Changing it to clasic bash if
condition.
Let only the init stage run so that we have a link on PRs to the CI and
can trigger it manually if desired. PR template updated with this info.
Also use yaml anchors for rules to reduce duplication.
By default, the API will fetch only 30 open PRs. This is enough currently
as we have 35 open ones. Bump the limit to the maximum. 100 should be enough
for some time. 🤞
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
With the quoting, we are passing an empty variable instead of no argument.
Also, if the skip is required, we are passing "-o ci.skip" instead of
"-o" "ci.skip".
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Save resources and needless CI runs by skipping the trigger-gitlab job if a PR is 'draft' (can be set in the pull request page at any time) or by setting a label "WIP".
Asside from saving resources, WIP PRs that don't trigger CI are a good message to a contributers to keep testing it locally and to only get the project resources after serious testing been made on their side.
