Closed VannTen closed 2 years ago
@VannTen: This issue is currently awaiting triage.
If a refinement session determines this is a relevant issue, it will accept the issue by applying the
triage/accepted
label and provide further guidance.
The triage/accepted
label can be added by org members by writing /triage accepted
in a comment.
Not sure if something is missing in the github-config.yaml ?
I believe it just needs the label-sync post-submit job to be run.
AFAIK this is currently only automatically triggered when there are changes that affect e.g. labels.yaml.
On Mon, Sep 19, 2022 at 04:29:14AM -0700, Pep Turró Mauri wrote:
I believe it just needs the label-sync post-submit job to be run.
AFAIK this is currently only automatically triggered when there are changes that affect e.g. labels.yaml.
From this line it should run also when community/github-config.yaml is changed.
/sig devsecops /priority critical-urgent /kind bug
From this line it should run also when community/github-config.yaml is changed.
Right.
I'm wondering if this might have been a race: the last time github-config.yaml
was touched was to create the repo (7abe7e642c95bbdfbf3adb05fedcfd9fa65075c7), at which point 2 postsubmit would run: peribolos and label-sync. I am guessing (as I can't find them in the job history anymore) that when label-sync ran, the repo was not yet there.
On Mon, Sep 19, 2022 at 10:18:48AM -0700, Pep Turró Mauri wrote:
From this line it should run also when community/github-config.yaml is changed.
Right.
I'm wondering if this might have been a race: the last time
github-config.yaml
was touched was to create the repo (7abe7e642c95bbdfbf3adb05fedcfd9fa65075c7), at which point 2 postsubmit would run: peribolos and label-sync. I am guessing (as I can't find them in the job history anymore) that when label-sync ran, the repo was not yet there.
Looks plausible. Long-term looks like we should add explicit dependency for the github-config.yaml... and prow support that by using tekton1 ^. Another needs for https://github.com/operate-first/apps/issues/2462
In the mean time, I don't know how we can trigger it manually ? Worst case we can do a bogus change on labels.yaml.
The label_sync
postsubmit job following operate-first/apps#460 failed (full log):
{"client":"github","component":"label_sync","file":"k8s.io/test-infra/prow/github/client.go:918","func":"k8s.io/test-infra/prow/github.(*client).log","level":"info","msg":"DeleteRepoLabel(thoth-station, opendatahub-cnbi, wontfix)","severity":"info","time":"2022-09-20T16:44:31Z"}
{"component":"label_sync","error":"failed to list labels: [status code 404 not one of [200], body: {\"message\":\"Not Found\",\"documentation_url\":\"https://docs.github.com/rest/reference/issues#update-a-label\"} status code 404 not one of [200], body: {\"message\":\"Not Found\",\"documentation_url\":\"https://docs.github.com/rest/reference/issues#update-a-label\"}]","file":"k8s.io/test-infra/label_sync/main.go:830","func":"main.main","level":"fatal","msg":"failed to update thoth-station","severity":"fatal","time":"2022-09-20T16:44:33Z"}
{"component":"entrypoint","error":"wrapped process failed: exit status 1","file":"k8s.io/test-infra/prow/entrypoint/run.go:80","func":"k8s.io/test-infra/prow/entrypoint.Options.Run","level":"error","msg":"Error executing test process","severity":"error","time":"2022-09-20T16:44:33Z"}
I don't know why label_sync
was trying to delete the (non-existing) wontfix
label :disappointed:
On the positive side, this happened after a bunch of label additions. It seems most of the labels are there now, and this worked now: https://github.com/thoth-station/opendatahub-cnbi/issues/10#event-7424475259
I believe the original issue is solved now. Not closing this just yet though in case we can clarify/follow-up on the postsubmit job failure
I don't know why
label_sync
was trying to delete the (non-existing)wontfix
label :disappointed:
wontfix
is one of the previous names of triage/unresolved
, so maybe
it's trying to do some sort of rename ? Should not choke on it not
existing though.
wontfix
is one of the previous names oftriage/unresolved
Right, but there are various other "previous" labels in labels.yaml
and they did not create problems so far AFAIK (on this or other repos - there have been a few label renames)
Should not choke on it not existing though.
Agreed. This might be a bug in label_sync
. I'm not sure how/if we could reproduce it, though. And a quick search in the test-infra repo did not bring anything relevant AFACIT.
Should we close this?
I think unless we encounter it again, it's probably good to close. And even if we do, it's quite minor.
/close
@goern: Closing this issue.
see https://github.com/thoth-station/opendatahub-cnbi/issues/10#issuecomment-1246553860