Packit-service: commit status is not updated when requesting a copr-build and PR is not from an admin/writer

[tyll]

In
https://github.com/nmstate/nmstate/pull/576

packit as a service did not build the copr package because the PR submitter is not an admin/writer to the repo. I requested a build in https://github.com/nmstate/nmstate/pull/576#issuecomment-593306511 and it seems that packit actually built it. But the status in the checks section still says Only collaborators can trigger Packit-as-a-Service

IMHO it should change to "in progress" after a permitted person requested a build and change back to this message when a new commit was pushed (if it wont't build it).

[lachmanfrantisek]

@tyll thanks for letting us know.

It "should" do it as you described. The PR status is actually the status of the last commit, but it looks good:

Maybe some GitHub caching issue?

[tyll]

Interesting, I see the different status in the commit list but at the bottom of the conversation tab it only shows the failed status for each packit job:

Usually this is updated right away. Not sure if this is now a GitHub problem or a packit problem.

[lachmanfrantisek]

Yes, I can see this as well.

Github does not have anything like PR status, they have only commit status and it's set correctly. Looks like a GitHub problem but I'll leave this open for a while for a case it will repeat.

[TomasTomecek]

@lachmanfrantisek There actually is PR status as well. Look at a pull request and there is a tab - checks.

[lachmanfrantisek]

@lachmanfrantisek There actually is PR status as well. Look at a pull request and there is a tab - checks.

It's only a dedicated view. Those checks are the checks of the HEAD commit of the PR.

[tyll]

@lachmanfrantisek There actually is PR status as well. Look at a pull request and there is a tab - checks.

It's only a dedicated view. Those checks are the checks of the HEAD commit of the PR.

The "checks tabs" is used by a different/newer API AFAIU. Not all checks that are visible for a commit appear in the "Checks" tab.

[lachmanfrantisek]

The "checks tabs" is used by a different/newer API AFAIU. Not all checks that are visible for a commit appear in the "Checks" tab.

Thanks, good to know. (We are still using the "old" API.)

[TomasTomecek]

what's the status here? should we revisit this once we redeploy prod? or is there something on p-s' side which we should fix?

[lachmanfrantisek]

what's the status here?

see my comment:
> Looks like a GitHub problem but I'll leave this open for a while for a case it will repeat.

should we revisit this once we redeploy prod? or is there something on p-s' side which we should fix?

I can check it after redeploy but, I still believe that the problem is not on our side.

[stale[bot]]

This issue has been marked as stale because it hasn't seen any
activity for the last 60 days.

Stale issues are closed after 14 days, unless the label is removed
by a maintainer or someone comments on it.

This is done in order to ensure that open issues are still relevant.

Thank you for your contribution! :unicorn: :rocket: :robot:

(Note: issues labeled with pinned or EPIC are
never marked as stale.)

[TomasTomecek]

I am going to close this one since I presume this is already fixed - we didn't have related issues for this recently and also the code for this changed significantly for the past 9 months. Thank you for taking time opening the issue and trying packit!

Please reopen or file a new one if you think something is not right.