Be able to retrigger the non-PR jobs

[lachmanfrantisek]

Currently, we can retrigger the jobs only in those two ways:

• PR comment for PR jobs => This needs to stay the same.
• Issue comments for propose-downstream => There is some hardcoding done in the code to match the release object.

We have at least two ways how we can allow retriggers or reactions with Packit:

• Create an issue with the known format. Some options (can be combined):
  • title == /packit propose-downstream 0.3.0 / /packit propose-downstream / /packit build master / ....
    • Reopening of the issue triggers the action again.
  • Any title, but react on commands in description or comment (same syntax as requested in #540 or #970)
• Create a commit comment with the command
  • How can we differentiate between branches and releases?
• Implement elsewhere -- e.g. via dashboard

Some more ideas? How other projects do that?

[csomh]

• Implement elsewhere -- e.g. via dashboard

I think this would be the most straightforward from a user experience point of view. And this is how I've seen it done at other CI services (Travis, for example). But for this to work we would need to implement authentication (with GitHub, for the start) in dashboard, so that the authorisation rules applied for reacting on pushes and comments could be used to give the users the option to re-trigger builds.

I would really not go for the other two solutions: both of them would offer a disconnected and convoluted experience, even though the first proposal would make some sense: we have jobs on some branch/release failing, so let's open an issue to fix that. But I wouldn't require the commands to be placed in the title, as that might lead to the issue list looking really strange.

Some more ideas? How other projects do that?

[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 don't have the capacity for this for now, but we would like to fix various small issues that usually caused a need for this. E.g. https://github.com/packit/packit-service/issues/1808

[praiskup]

@lbarcziova pointed me to this issue, JFTR, GitHub allows us to comment on commits like this: https://github.com/rpm-software-management/tito/commit/9d1c10f52fe08b879280a80108fbbee0cff8b75b#comments

[praiskup]

I agree this is a corner case; I've hit the problem because there was a very short packit.service downtime :-) but if it happens, there's no other way to retrigger the build than push another commit :-) which might not always be the acceptable way out from this.

[lbarcziova]

Reopening as this causes really bad UX - no simple way to retrigger e.g. a build for commit.

[lbarcziova]

#1595 could help resolve this as well.

[lbarcziova]

Create a commit comment with the command

to me, this sounds like the most natural place, but we would still need to figure out how to differentiate whether the person wants to retrigger the commit or release trigger job (a comment command argument sounds reasonable)

#1595 would be also a nice thing to have, but would solve this only partially - it would not solve the issue when there are no check runs by Packit, e.g. there is an outage and Packit doesn't react to a commit at all