Deprecate multi-approvers.yaml workflow

[ian-shafer]

The new multi-approvers GH Action should be used instead.

[ian-shafer]

@sethvargo is there a defined process for this?

My initial idea is to

1. Set a deprecation date
2. Update the README to warn that this is deprecated and add migration instructions
3. Add a warning message that shows up in the runner logs when the workflow is run

Optionally, once we reach the deprecation date, we can add an input (e.g. use-deprecated-workflow-at-my-own-risk) that would allow folks to use it past the deprecation date for some time.

Or, maybe this is overkill and we can just delete it because, most likely, there are not many people using this.

[sethvargo]

Assuming inputs can be mapped, we print a deprecation warning and then call the new workflow with the inputs. @dcreey did this already for all the other ones that moved.

[ian-shafer]

Unfortunately, the two are not backward compatible because actions/multi-approvers does not take a JSON membership file, and actions/multi-approvers requires a token for the team membership calls to the GH REST API.

[sethvargo]

Do we know who is using the original one?

[ian-shafer]

I know of one user, @meltsufin. But I'm not even sure if he's actively using it or just evaluated it. I reached out to him to find out.

Technically, there could be others as this is a public repository.

[ian-shafer]

@meltsufin confirmed that the pkg/multi-approvers is used here. So there's at least one known instance.

He plans on migrating to the new actions/multi-approvers next week.

[ian-shafer]

@meltsufin is going to pin to abcxyz/pkg/.github/workflows/multi-approvers.yml@1d1cedf7768d17dde23bb2cda24bc1fb950e9f92.

That covers the one use case we know of.

Open question: Do we need to worry about uses that we don't know about?

The actual work to do this is pretty low (update README, add warning, add new input to run past deprecation date) so I lean to do a proper deprecation as laid out above.

[pdewilde]

An existing user should be using a pinned workflow, which means they wouldn't see the deprecation notice unless they tried to update.

[meltsufin]

Pinning here: googleapis/google-auth-library-java#1737.
I'll try to migrate to the GitHub team version soon.

[sethvargo]

With @ian-shafer changing teams, is there someone who can pick up the migration efforts?

[meltsufin]

FWIW, we're using the GH action, and don't need this workflow anymore.

[ian-shafer]

AFAIK, there are no users of this workflow. So I expect deprecation to be relatively easy.

I think the next step is to delete the files, and remove mentions of the workflow from the README. If there are any users who are pointing to HEAD, they'll break, but this is probably okay since there is a work-around (pin to a commit).

@billnapier may be able to find an owner for this.

[billnapier]

@bradegler for now