Do daily builds of systemd using the current packaging, but against the latest tip of https://pagure.io/projects/centos-sig-hyperscale/systemd . This will run the unittests, which would give us useful signal, and produce RPMs as a byproduct that one can use to run further testing.
Metadata Update from @dcavalca: - Issue tagged with: systemd
Tentative plan (somewhat mimicking what FB was doing internally): - have a c8s-sig-hyperscale-cd branch with some stub packaging - have a script that uses some sed magic to point the specfile to the desired hash - somehow kickoff a CBS build - tag it so it gets published (-testing on buildlogs is probably good enough to start with)
c8s-sig-hyperscale-cd
Does it need publishing? You could just pluck the builds right out of the CBS Koji instance...
Yeah, that could work too. Also, I don't think this even needs a dedicated branch. Here's what I have so far (untested, mostly copypasta from the internal version):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
#!/bin/sh SYSTEMD_ENDPOINT='https://api.github.com/repos/systemd/systemd' AUTHOR='systemd-cd <noreply@centos.org>' SYSTEMD_COMMITS='https://github.com/systemd/systemd/commits' SYSTEMD_RELEASES='https://github.com/systemd/systemd/releases' last_tag=$(curl -L -s "${SYSTEMD_ENDPOINT}/tags" | jq -r '.[0].name') last_commit=$(curl -L -s "${SYSTEMD_ENDPOINT}/commits?sha=master" | jq -r '.[0].sha') short_commit=$(echo "$last_commit" | cut -c1-7) git clone https://git.centos.org/rpms/systemd.git cd systemd git checkout c8s-sig-hyperscale systemd_tarball="SOURCES/systemd-${short_commit}.tar.gz" curl -L -s -o $systemd_tarball https://github.com/systemd/systemd/archive/${last_commit}.tar.gz" # v242-rc2 -> 242~rc2 version=$(echo "${last_tag#?}" | tr '-' '~') # the date is to ensure the release is always monotonically increasing # e.g. 1.20190320.4bf953d.fb1 release="1.$(date +%Y%m%d).${short_commit}" rpm_version="${version}-${release}" changelog="$(date '+%a %b %d %Y') ${AUTHOR} - ${rpm_version}" sed -i "SPECS/systemd.spec" \ -e /^Patch.*/d \ -e "s/^#global commit .*$/%global commit ${last_commit}/" \ -e "s/^Version:.*$/Version: ${version}/" \ -e "s/^Release:.*$/Release: ${release}/" \ -e "/%changelog/a * ${changelog}\\n- Auto build from ${last_commit}\\n" rpmbuild --define "%_topdir $PWD" -bs SPECS/systemd.spec cbs build --scratch hyperscale8s-packages-main-el8 SRPMS/systemd*.src.rpm
This would need to be ported to Pagure (as I'd rather hit our mirror than GitHub all the time), and we'd need to find a way to actually issue the cbs build (I guess via a bot account of some sort?).
Yeah, we could definitely do that. Is cbs using pyrpkg like centpkg or fedpkg does?
cbs
pyrpkg
centpkg
fedpkg
cbs is basically a wrapper around koji afaict; I don't see any reference to pyrpkg specifically. Also open to using something else, we basically just need a way to submit a scratch build here.
koji
If it's just a wrapper around koji, we can just do a similar wrapping for our needs. The shell script you've got is probably a good starting point.
Filed https://pagure.io/centos-infra/issue/291 to get the infra conversation started.
Metadata Update from @dcavalca: - Issue tagged with: meeting
Cleaned up the script, tested it in https://cbs.centos.org/koji/taskinfo?taskID=2472057 and put it at https://pagure.io/centos-sig-hyperscale/systemd-releng/blob/main/f/systemd-cd.sh to make it easier to work on. I've also filed https://pagure.io/pagure/issue/5152 on Pagure, which will allow us to drop the github dependency.
I've registered an hyperscalebot account for this and have sponsored it into the SIG.
hyperscalebot
Thinking about this some more, I think I'd rather have dedicated tags to keep things clean. Filed https://pagure.io/centos-infra/issue/299 for that.
It's alive! https://cbs.centos.org/koji/tasks?owner=hyperscalebot&state=all
This is working well
Metadata Update from @dcavalca: - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.