I would like to be able to rerun my own travis jobs.

[jberkhahn]

Feature Request

To manually restart jobs in travis, you need admin privileges on the linked github repo. It would be great if non-admin developers (such as myself), had a mechanism to rerun tests in the event of a flake or what have you. I know the main kube repos have a git robot that can do this if you comment '/retest'.

Is your feature request related to a problem? Please describe. I can't rerun my own tests without forcefully changing the commit SHA somehow. I cannot rerun tests on others PRs at all.

Describe the solution you'd like Some way to kick travis tests.

[joelanford]

There are some options here that need to be investigated:

1. We can move to Red Hat OpenShift's prow instance, but this would require us to port our e2e test setup, which is not trivial due to the fact that prow jobs run in containers that lack access to docker sockets. We would need alternate ways to spin up clusters and build images used in the e2e tests.
2. We may be able to move to GitHub Actions. We would need to investigate what PR authors and repo approvers/reviewers would be able to do (ideally with slash commands)
3. Same as 2, but stay on travis.

[jberkhahn]

I did some investigation around Github Actions. It seems a bit kludgy, but possible. Defining a github action basically consists of some light scaffolding around a Dockerfile. So we'd have to define a Dockerfile with the scripts and such for each test we want to run baked in. I don't see anything about unrestricted access to the docker socket, and assume we can't get that unless we host our own Github Actions server, which is an option apparently. Poking around a bit in my fork of OperatorSDK vs here, it looks like you require write access to be able to manually rerun Actions, and it's away in some weird menu that's not really anywhere near your PR. There looks to be github robots to let you do it with comment commands on the PR itself, though.

[joelanford]

Here’s an example of something we could do: https://github.com/joelanford/helm-operator/blob/plugin/.github/workflows/ci.yml

A good chunk of that could be refactored into scripts in the repo, but I don’t think we’ll need any custom Dockerfile-based action implementations.

[jberkhahn]

Bunch of discussion from the meeting. The decision was made to investigate Github actions at this time instead of Prow at this time as we know converting to Prow would be a bunch of work, and we can always switch to Prow later if Github actions don't work.

This issue is now tracking progress on:

1. try to write a github action to rerun my travis jobs while changing as little as possible 1a. investigate the possibility of implementing /commands via github actions to do other things such as adding labels to Github issues.

Things that are related and have been created as their own issues:

2. 4110 make CI jobs run in Github actions

3. 4112 make the state of the master CI jobs more obvious to developers