#40 systemd daily builds for CI
Closed 2 years ago by dcavalca. Opened 2 years ago by dcavalca.

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

2 years ago

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)

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 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.

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.

Metadata Update from @dcavalca:
- Issue tagged with: meeting

2 years ago

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.

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.

Metadata Update from @dcavalca:
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata