test change

[martinpitt]

No description provided.

[martinpitt]

Test triggering anaconda from packit COPR check_run against my main commit e74c8e8

With commit 240d2b7 , most unrelated check runs are now properly skipped, but there are two successful runs which are related to the rawhide/x86_64 copr build, and claim "conclusion": "success" and even "title": "RPMs were built successfully..

Only the third run happend after the binary rpm build completed.

Or perhaps these were builds from previous SHAs? But no, even the first run says GITHUB_SHA: e74c8e8a... which is the current version of my main fork at this point. Also, all three logs have sha: f4ddb52 which is the current version of this PR/my test-change branch. 🤯

Diffing the github object between first and third has some noise (time stamps, runner IDs, etc.), and only one significant one: check_suite.{after,head_sha} moves from 6acd1b7 (old version of this PR) to f4ddb52 (current version).

So it looks like the first and second run were for previous force-pushes; so the whole reason why I wanted to move to this was to get some ordering guarantee without having to predict packit's merge commit SHA. But with that it just makes the whole structure more complicated -- we get a lot of unnecessary workflow runs, and they don't appear in the PR, and we don't get the nice on.pull_request.paths: filter.

[martinpitt]

Next experiment: I reopened this PR, which re-triggered RPM builds. I force-pushed while that was still ongoing, as I want to check the apparent one hour difference between GitHub and real time. I suspect that the log timestamps in GH are UTC+1, but let's find out.

The first run is indeed for commit f4ddb52 before the force-push, the second run for current version 3838732.

date on the workflow runner says Tue Oct 17 07:23:30 UTC 2023, which is at least the right time zone. So this matches with the srpm build which has version 271.1-1.20231017071938956615, i.e. 4 minutes earlier (which is a plausible time for the binary RPM build).