Packit-service: Gitlab commit status cannot transition via "enqueue"

[shreyaspapi]

This is a known issue of while working on GitLab API - issue

[2020-07-16 07:01:59,138: ERROR/ForkPoolWorker-1] Task TaskName.pr_comment_copr_build[8e2e7cd3-9757-4637-b0bd-c97f12d56ad2] raised unexpected: GitlabCreateError('Cannot transition status via :enqueue from :pending (Reason(s): Status cannot transition via "enqueue")')
worker              | Traceback (most recent call last):
worker              |   File "/usr/lib/python3.7/site-packages/gitlab/exceptions.py", line 251, in wrapped_f
worker              |     return f(*args, **kwargs)
worker              |   File "/usr/lib/python3.7/site-packages/gitlab/mixins.py", line 204, in create
worker              |     **kwargs)
worker              |   File "/usr/lib/python3.7/site-packages/gitlab/__init__.py", line 604, in http_post
worker              |     post_data=post_data, files=files, **kwargs)
worker              |   File "/usr/lib/python3.7/site-packages/gitlab/__init__.py", line 510, in http_request
worker              |     response_body=result.content)
worker              | gitlab.exceptions.GitlabHttpError: 400: Cannot transition status via :enqueue from :pending (Reason(s): Status cannot transition via "enqueue")

We can easily catch specific GitlabExceptionAPI and ignore the error while reporting the commit status, which would solve it (But rather it's like a workaround solution). Another way would be to check the current commit status and act accordingly (Would take a lot of time to get the current commit status.).

[TomasTomecek]

could you please clarify what the exact problem is? shall we bypass enqueue then?

[shreyaspapi]

@TomasTomecek Sorry if this was not clear.

The exact issue is in Gitlab where we cannot overwrite the status of a pending build -> pending build again. We can bypass the enqueue but ignoring the error here should also work fine.

740 Should solve the issue

[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, security, bug or EPIC are
never marked as stale.)

[TomasTomecek]

anything else we can do here?

[shreyaspapi]

@TomasTomecek Yes, we can have unique status for each step of the workflow? e.g. packit-service/copr-build-srpm, packit-service/copr-build-fedora-31-rpm. I will make a pr for this.

[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.)

[lachmanfrantisek]

We need to solve this if we want to support GitLab properly.

[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.)

[lachmanfrantisek]

The current state looks good to me. Let's close this issue and create a new one (more specific) if needed.