Open dustymabe opened 5 years ago
request a new koji tag and automated building + repo generation
This option is the one that I prefer. If no one objects I can start conversations to see if this is feasible.
request a new koji tag and automated building + repo generation
This option is the one that I prefer. If no one objects I can start conversations to see if this is feasible.
+1
request a new koji tag and automated building + repo generation
To confirm, in this model, we wouldn't be spamming dist-git every hour, right?
To confirm, in this model, we wouldn't be spamming dist-git every hour, right?
Not sure what you mean by spamming. Can you be more specific?
I guess I'm just trying to understand how it'd work. Would this essentially be like fedpkg push && fedpkg build
or fedpkg build --srpm
?
I guess I'm just trying to understand how it'd work. Would this essentially be like
fedpkg push && fedpkg build
orfedpkg build --srpm
?
My thoughts are that we would have a separate branch in dist-git that we update with bots (i.e. automated). SCM syncing, Builds, tagging, repo generation would be automatic.
I built rpm-/ostree rpms from master in a copr repo recently: https://copr.fedorainfracloud.org/coprs/lorbus/rpm-ostree/packages/
I had to change both spec files to accomodate this (see https://github.com/LorbusChris/ostree-spec and https://github.com/LorbusChris/rpm-ostree-spec) . This might be helpful as a reference in case we choose to use COPR for our continuous builds.
Note so self: https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation#Packaging_a_release_.28except_for_GitLab.29
https://pagure.io/packaging-committee/issue/719
https://pagure.io/packaging-committee/pull-request/826
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/51
I would scope this to a much larger set of things. It's not just build tools it's also things we ship in the host. For example we clearly want https://github.com/coreos/ignition from master and for that matter https://github.com/coreos/ignition-dracut/ etc etc.
And I see no reason we shouldn't e.g. have builds that track systemd git master and for that matter the kernel. And NetworkManager, podman.
I would scope this to a much larger set of things. It's not just build tools it's also things we ship in the host.
I 100% agree so that we can have a more continuous build (and CI) of FCOS itself. I see the same mechanism we set up for the build tools being able to be used for this purpose.
Opened a ticket for releng to create us a tag and dist-repo (automatically generated based on rpms tagged into koji tag) for us to experiment with: https://pagure.io/releng/issue/8165
Probably orthogonal to the Koji tags: Source-Git aka Packit for rpm automation. Tomas said he hopes a first usable version will be ready in ~2 weeks. I'll definitely use that for greenboot.
Probably orthogonal to the Koji tags: Source-Git aka Packit for rpm automation. Tomas said he hopes a first usable version will be ready in ~2 weeks. I'll definitely use that for greenboot.
yep. I actually gave the documentation a read through yesterday and watched the video from devconf. I'm excited to learn more and give feedback.
I am still a bit skeptical about packit. But anyways just a note, I did create https://copr.fedorainfracloud.org/coprs/g/CoreOS/continuous/ and kind of try to maintain it here and there.
In our current state of heavy development we have a need to iterate fast on our build tools for Fedora CoreOS. In the past we have been achieving this goal by setting up rdgo in centos CI. The problem is that the current setup does not support multi-arch.
We need to find a solution that includes multi-arch but also gives us fast access to builds. Options include:
The build tools we would currently set this up for include