Extend CI to cover older systems to check that no compilation regressions occur

[keszybz]

No description provided.

[mrc0mmand]

Hey, should I enable CentOS CI and Travis CI for this repo as well, or you have something else in mind?

[keszybz]

That is one possibility. I also discussed with @poettering simply moving the stable branches to the main systemd repo, so that they'd be covered by existing CI. What do you think?

[mrc0mmand]

That sounds even better, as it would keep the CI configuration less scattered.

[Conan-Kudo]

I'm honestly surprised that this repo isn't just part of the main systemd repo...

[keszybz]

Yeah, after talking this over we agreed to merge it all into the main repo. I'll do that one day.

[evverx]

I'm not sure who you were talking to but given that Ubuntu CI, Semaphore CI, Azure Pipelines, Fuzzit, FuzzBuzz, Coverity Scan and partly Travis CI (basically everything except for CentOS CI) are maintained kind of outside of this inner circle it would be great if you could share the details of your decision.

[evverx]

@ddstreet to judge from https://salsa.debian.org/systemd-team/systemd/blob/5da4807394b2bff5108f4c7d322fe760f004dfa6/debian/extra/checkout-upstream#L68, it seems Ubuntu CI always rebases PRs on top of master. If you have access to the scripts dealing with requests the webhooks send, could you extract branches PRs are opened against there and pass them to checkout-upstream? Another option would be to simply skip PRs against "stable" branches on the Ubuntu CI side (because that's how it will most likely be handled everywhere else).

[ddstreet]

@ddstreet to judge from https://salsa.debian.org/systemd-team/systemd/blob/5da4807394b2bff5108f4c7d322fe760f004dfa6/debian/extra/checkout-upstream#L68, it seems Ubuntu CI always rebases PRs on top of master. If you have access to the scripts dealing with requests the webhooks send, could you extract branches PRs are opened against there and pass them to checkout-upstream? Another option would be to simply skip PRs against "stable" branches on the Ubuntu CI side (because that's how it will most likely be handled everywhere else).

So, @rbalint has this commit proposed:
https://salsa.debian.org/systemd-team/systemd/merge_requests/49/diffs?commit_id=ca49f019191a1b7a19ba02f1c6f4c71eac8c4ce7
that would allow specifying an alternate repo, which could be used to test against this systemd-stable repo.

As far as which branch to rebase against if/when this systemd-stable repo gets moved to a branch of the main systemd repo, it should be easy to add a new env var to specify that in the checkout-upstream script, and the test hooks here could just pass that var to Ubuntu CI when running tests for stable PRs.

[rbalint]

@ddstreet The idea behind setting the repo was using a local clone to speed up bisecting, but indeed, this could be used to test systemd-stable. BTW IMO instead of rebasing on top of master it would be better to merge the PR and also detect the PR's target branch instead of hardcoding only master in the script.

[evverx]

FWIW yesterday I received a couple of notifications from Semaprhore basically saying that the systemd-stable repository is broken there so before moving the stable branches to the systemd repository, apart from pointing CI to the right branches, it would probably make sense to think about how the testing infrastructure is going to be backported or, maybe, whether it's feasible given that to my knowledge the master branch is barely kept "green".

[ojab]

Looks like systemd-stable uses semaphore v1 and didn't switched to v2.
AFAIU systemd-stable project should be added to the https://the-real-systemd.semaphoreci.com/ organization and it would just work.
Maybe removal of the old integation from github project settings would also be needed though.

I did it with my fork and it just works

[bluca]

mmh I don't see a button to add another repository to the same project

[mrc0mmand]

Lemme take a look...

[bluca]

I think I found it

[ojab]

https://semaphoreci.com/systemd/systemd-stable/branches/pull-request-143/builds/1

[ojab]

Ok, it still goes to the v1 though ._.

[mrc0mmand]

Should be fixed, see #144. I configured the project in the v2 instance and disabled the v1 one.

[ojab]

Why not just start containers with different distros on GHA, though and run the build inside? I guess it should work sans GHA concurrent instances limit, but single debian build like it works not in semaphoreci shouldn't take much time.

[bluca]

Should be fixed, see #144. I configured the project in the v2 instance and disabled the v1 one.

nice, thanks! with the recent packit fix I guess we can close this?

[mrc0mmand]

Why not just start containers with different distros on GHA, though and run the build inside? I guess it should work sans GHA concurrent instances limit, but single debian build like it works not in semaphoreci shouldn't take much time.

We already have quite a lot of jobs in GHA, so adding another bunch of them on top of that might be a bit too much (also, having the CI configuration same with the upstream repo is also a plus, as it makes backports easier).

And the Semaphore job does is a different environment, which, in a couple of cases, managed to catch issues other CIs missed.

nice, thanks! with the recent packit fix I guess we can close this?

I think so, since the original goal of this issues was to cover the build part of the systemd build.

[mrc0mmand]

Also, see systemd/systemd#21330 which should introduce most of the remaining GHA-based CIs to the stable branches.

[bluca]

This is now implemented for v249-stable (thanks @mrc0mmand !), so closing