Looking at the https://fedora.softwarefactory-project.io/zuul/project/github.com/fedora-infra/the-new-hotness the jobs are registered properly, just not executed on the PRs :-/

CC @fbo

@fbo Did you have time to look at this? I'm currently blocked on it and I can't figure out what actually happened.

Tested again today on https://github.com/fedora-infra/the-new-hotness/pull/439, but still not caught by Zuul.

Hi

First I notices that new jobs (fi-*) are defined in multiple branches https://fedora.softwarefactory-project.io/zuul/job/fi-tox-bandit. The page reports (anitya, anitya, main) so it seems (as fedora-infra/zuul only have "main" branch) that two other repos own an "anitya" branch. Could you remove those branches if not needed. It might happen that Zuul does not match the context because it create job variants out of the branches.

logs reports:

2022-04-14 10:03:07,604 DEBUG zuul.layout: [e: 0e147890-bbda-11ec-961f-01ae96f75ffa] Collecting jobs fi-tox-bandit for <Change 0x7fb0d4b74978 fedora-infra/the-new-hotness 439,d802364b0e434374c203825ed35dd95280025c42>
2022-04-14 10:03:07,604 DEBUG zuul.layout: [e: 0e147890-bbda-11ec-961f-01ae96f75ffa] Collecting job variants for fi-tox-bandit
2022-04-14 10:03:07,604 DEBUG zuul.layout: [e: 0e147890-bbda-11ec-961f-01ae96f75ffa] Variant <Job fi-tox-bandit branches: {MatchAny:{ImpliedBranchMatcher:anitya}} source: fedora-infra/zuul/.zuul.yaml@anitya#514> did not match <Change 0x7fb0d4b74978 fedora-infra/the-new-hotness 439,d802364b0e434374c203825ed35dd95280025c42>
2022-04-14 10:03:07,604 DEBUG zuul.layout: [e: 0e147890-bbda-11ec-961f-01ae96f75ffa] Variant <Job fi-tox-bandit branches: {MatchAny:{ImpliedBranchMatcher:anitya}} source: fedora-infra/zuul/.zuul.yaml@anitya#514> did not match <Change 0x7fb0d4b74978 fedora-infra/the-new-hotness 439,d802364b0e434374c203825ed35dd95280025c42>
2022-04-14 10:03:07,605 DEBUG zuul.layout: [e: 0e147890-bbda-11ec-961f-01ae96f75ffa] Variant <Job fi-tox-bandit branches: {MatchAny:{ImpliedBranchMatcher:main}} source: fedora-infra/zuul/.zuul.yaml@main#514> did not match <Change 0x7fb0d4b74978 fedora-infra/the-new-hotness 439,d802364b0e434374c203825ed35dd95280025c42>
2022-04-14 10:03:07,605 DEBUG zuul.layout: [e: 0e147890-bbda-11ec-961f-01ae96f75ffa] No matching parents for job fi-tox-bandit and change <Change 0x7fb0d4b74978 fedora-infra/the-new-hotness 439,d802364b0e434374c203825ed35dd95280025c42>

ok here I see that there is a branch anitya in fedora-infra/zuul but it seems the branch no longer exists now.
Maybe we need force a re-load of the config for the fedora tenant as Zuul seems to believe that branch exists. I'll check with my team mates.

@fbo thanks, this branch was only for the PR in https://pagure.io/fedora-infra/zuul and as you can see it's already deleted.

Ok, unfortunately I don't have access to the log of 6 days ago but Zuul should have received the notification that the branch has been deleted and removed it from its cache.

Either there is a bug on the driver or either the branch deletion event has not been received.

But I'd like to advice to create a fork even for repositories you own in order to create PRs. This will prevent having regular short lived branches in refs/head/ that might contain zuul config.

Also the Pagure driver for Zuul lacks of features compared to the Github or Gitlab driver where for instance we cannot prevent Zuul to read Zuul config from "unprotected" branches [1].

1: https://zuul-ci.org/docs/zuul/latest/tenants.html#attr-tenant.untrusted-projects.%3Cproject%3E.exclude-unprotected-branches

Hm, this could be it, I didn't used fork for creating the PRs. I will use the forks from now on on this repo.

It seems like the PRs are now correctly tested by Zuul, thanks for your assistance.

Yes it seems the zuul full-reconfigure command refreshes as expected the Pagure connection cache.