Consider moving pagure.io/workstation-ostree-config to GitHub or to Fedora's GitLab

[travier]

Consider moving https://pagure.io/workstation-ostree-config to GitHub (here) or to Fedora's GitLab namespace (https://gitlab.com/fedora).

The main advantage of this change would be that it would be much easier for us to setup CI to validate changes to this repo.

We can setup Zuul based CI for repos in pagure.io (https://fedoraproject.org/wiki/Zuul-based-ci) but I don't think that we have contributors with knowledge about Zuul and we have much more contributors with GitHub or GitLab CI knowledge.

[travier]

CC @tpopela @dustymabe @jlebon @cgwalters

[dustymabe]

You might be blocked from doing this because of fedora/infra and/or pungi requirements. I don't know if it can pull from GitHub or GitLab when doing the OSTree composes.

[travier]

I think we should be able to keep the pagure repo as a mirror of the one in GitHub/GitLab if that's an issue (pushing from here to Pagure for each commit).

[tpopela]

As I've already shared with Timothee in the past, my long term vision is to move everything from the fedora-silverblue organization here on GitHub to Fedora's GitLab (when it's really ready).

[travier]

Do we have any approximative timeline for when it should be ready? Some projects are already there. What's missing for it to be ready?

[tpopela]

No AFAIK - I'm waiting for someone to figure out how the whole situation with "mentions" will look/work like. Because I want to be able to mention anyone in the Fedora Project with their FAS and the user should get the notification (even though they might not use Fedora's GitLab). Let me ask mattdm about this again and if it will be somehow addressed.

[travier]

I've asked:

• https://pagure.io/releng/issue/11003
• https://pagure.io/fedora-infrastructure/issue/10873

[travier]

• pagure.io/releng/issue/11003

It's likely doable:

It would need changes to allowed scms in the kojid config: https://pagure.io/fedora-infra/ansible/blob/main/f/roles/koji_builder/templates/kojid.conf#_81

And also changes to the builder's firewalls to allow them to reach it over the net.

I think this is doable, but we want to make sure we don't open all of gitlab, only specific repos.

[travier]

And we now have https://gitlab.com/fedora/ostree. Feel free to request access by opening an issue there.

[travier]

See #359 (comment) for an update.

[travier]

You can use the following command to try them:

$ sudo rpm-ostree rebase --experimental ostree-unverified-registry:quay.io/fedora-ostree-desktops/silverblue:rawhide.20220928.0.29c1e070

[AdamWill]

We can setup Zuul based CI for repos in pagure.io (https://fedoraproject.org/wiki/Zuul-based-ci) but I don't think that we have contributors with knowledge about Zuul and we have much more contributors with GitHub or GitLab CI knowledge.

I think you're kinda overstating this part, FWIW. I don't know a whole lot about Zuul either, but the integration has been set up to be very very simple. The first time I onboarded a project to the Zuul-based CI for Pagure it took me about two hours with zero prior knowledge of Zuul.

This might vary a bit depending on how specific the requirements are for running your test suite, but it's really not difficult. There are docs and example configs and what you wind up with is a VM or containerized Fedora environment in which to run the test suite.

edit: I revised the wiki page you linked to be a bit better (I hope, at least). Asked Tristan to check it for accuracy.

[travier]

I've made https://pagure.io/fedora-project-config/pull-request/229 & https://pagure.io/workstation-ostree-config/pull-request/309 to give it a try.

[travier]

@AdamWill Do you know if it is possible to trigger a Zuul job daily on a Pagure repo?

[AdamWill]

Not sure about that, fbo or tristan might know.

[travier]

I've setup nightly builds for Silverblue & Kinoite in https://gitlab.com/fedora/ostree/ci-test (repo name expected to change).
Testing those from an existing installation is:

$ sudo rpm-ostree rebase --experimental ostree-unverified-registry:quay.io/fedora-ostree-desktops/silverblue:rawhide
$ sudo rpm-ostree rebase --experimental ostree-unverified-registry:quay.io/fedora-ostree-desktops/silverblue:37

and similarly for F36 and Kinoite. You can find all builds (tags as they are container images) on Quay.io (repo names also expected to change): https://quay.io/repository/fedora-ostree-desktops/silverblue?tab=tags & https://quay.io/repository/fedora-ostree-desktops/kinoite?tab=tags.

I'm still having issues building installer ISOs with lorax: https://gitlab.com/fedora/ostree/ci-test/-/issues/1. Will have to give it a try again soon.

[travier]

We should consider signing those images. A few links for reference:

• Switch to signed images ublue-os/main#28
• https://universal-blue.org/tinker/setup/manual/?h=cosign#3-set-up-container-signing
• https://universal-blue.org/blog/2023/07/19/sigstore-signed-images-are-now-here/
• https://github.com/containers/image/blob/main/docs/containers-policy.json.5.md#policy-requirements

[travier]

Closing this issue in favor of the one in the Fedora Atomic Desktop issue tracker: https://gitlab.com/fedora/ostree/sig/-/issues/4

[jmpolom]

We should consider signing those images. A few links for reference:

• Switch to signed images ublue-os/main#28
• https://universal-blue.org/tinker/setup/manual/?h=cosign#3-set-up-container-signing
• https://universal-blue.org/blog/2023/07/19/sigstore-signed-images-are-now-here/
• https://github.com/containers/image/blob/main/docs/containers-policy.json.5.md#policy-requirements

Going to add some info on this closed issue because I don't see any other place to reference this. There is a discussion in an rpm-ostree issue (coreos/rpm-ostree#4272 (comment)) about a deficiency in the container library related to supporting cosign/sigstore signatures. Right now all that works is boring old static on disk keyfiles (questionable security).

There was a draft PR submitted to correct this in the containers/image library but there were some issues with the submitted PR and other unresolved contention about how to actually achieve the needed features: containers/image#2235

I think this an area of future needed cooperation and coordination amongst the respective Red Hat sponsored projects.