[RFE] Allow re-run of existing cross repo

[NickLaMuro]

Generally speaking, when using cross_repo_test, you aren't going to nail it on the first go.

Unfortunately with the current implementation of cross_repo_test, @miq-bot owns the PR, so it is the only one that re-trigger the build.

The feature here would be to allow a way of retriggering the cross repo build so that you can test again with the latest commits.

Option #1

A first pass might just be adding a new command that looks like this:

@miq-bot cross_repo_retest ManageIQ/manageiq-cross_repo-tests#1234

And the bot will close/open that PR, re-triggering the cross repo tests. This doesn't address making changes to what is being tested, so some further thought for how to make additions to that would need to be considered.

Option #2

Re-use cross-repo-tests, but allow for no-args. If a previous cross-repo-tests command is detected, then it will just use that PR.

@miq-bot cross_repo_tests

This would also allow for adding additions or subtractions if needed, as you could just take the original command, and add/subtract from it. In this form, it would just re-write the existing commit if a PR is already detected.

[Fryguy]

No need to specify the PR if you're in the PR... @miq-bot cross-repo-retest is sufficient

[Fryguy]

I was thinking something like option 2. A bare call would retest (close/open PR or just kick directly via Travis API). Additionally, sometimes you get the list of repos wrong, so this would allow re-requesting with a different set of repos. I would just do a replace though; supporting add/remove repos is just too complicated, so just force the user to re-specify the whole thing.

[chessbyte]

How about the simpler @miq-bot retest on the PR?

[NickLaMuro]

@chessbyte I think the reason for that is it doesn't solve the second problem of being able to update the original cross repo run.

If we overload the existing functionality slightly (allow for "no args" to trigger a retest), we can also handle the case where tested repos need to be updated.

An example of where needing to update would happen would have been the Rails 6 effort:

ManageIQ/manageiq#19977

Where the list of repos to be tested expanded over time as we knew the full extent of what needed to be fixed as we upgraded, but allowing a smaller subset to be worked on at first to reduce the scope initially.

Reviewers could also think of what needs to also be validated after a initial cross repo has been issued.

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.

[kbrock]

I like the idea of not adding a new command

You can specify a new list and it will update the existing one, otherwise or it will just kick it.

Not sure if we need to check if it is still open.

[miq-bot]

@NickLaMuro unrecognized command 'cross_repo_retest', ignoring...

Accepted commands are: add_label, add_reviewer, request_review, assign, close_issue, cross_repo_test, move_issue, remove_label, rm_label, remove_reviewer, set_milestone, unassign

[miq-bot]

@NickLaMuro 'cross-repo-test(s)' command is only valid on pull requests, ignoring...