fix: Use paulfantom/periodic-labeler for labeling PRs

[ericclemmons]

[Delivers #170288921]

The labeler runs successfully on PRs from aws-amplify, but not on forks with this error:

actions/labeler#16 (comment)

This is known, but surprising behavior:

yogstation13/Yogstation#7203

The fix is to switch to periodic-labeler, which runs on a cron within the scope of aws-amplify, vs. a PR event which runs in the restricted context of the fork:

actions/labeler#12 (comment)

https://github.com/marketplace/actions/periodic-labeler

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[codecov]

Codecov Report

Merging #4568 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #4568   +/-   ##
=======================================
  Coverage   76.24%   76.24%           
=======================================
  Files         174      174           
  Lines        9619     9619           
  Branches     1964     1964           
=======================================
  Hits         7334     7334           
  Misses       2140     2140           
  Partials      145      145

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8674120...8338bff. Read the comment docs.

[sammartinez]

This makes sense to me on what is needed to have this fix our labeling of PRs, Im not sure on using this repo as we would be possibly exposing secrets in order to label. @mlabieniec what do you think of using this?

[sammartinez]

Are we worried about https://github.com/marketplace/actions/periodic-labeler not be certified by github? @mlabieniec

[ericclemmons]

It's not an unreasonable concern: the image referenced (owned by GitHub or otherwise) should still be reviewed and referencing an explicit tag.

I generally regard build tooling with the same scrutiny as NPM dependencies (though they have access to the same, if not more, secrets).

This PR is the "quick fix" based on my research, but we have several options to resolve it if this user's fork doesn't meet our standards!

[ericclemmons]

There is another option, and that's to own it ourselves:

• https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-a-javascript-action#example-using-a-private-action

I hesitate to do this because we already own this workflow, but in a very manual way.

1. Close this, keeping the status quo of manually keeping PRs & labels up-to-date. (This will always exist in some capacity IMO).
2. Merge this automated solution, delegating the problem to a dependency. (Not unlike the purpose of NPM packages)
3. Create a new PR for an automated, private workflow. More effort, and I'd rather have Option 1 if Option 2 isn't desirable for whatever reason.

[ericclemmons]

Making the 🕴️_executive_🕴️ decision to close this.

Our PRs overwhelmingly go unlabeled, which makes triaging more difficult (whether by category or "needs review"):

https://github.com/aws-amplify/amplify-js/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc

Improving our issue -> PR pipeline (per my open-source doc) will also mitigate this, as tooling can couple issues with PRs so that they are collated in the pipeline to completion.

[ericclemmons]

Also, no idea how a "levitating man in suit" is a thing.

[github-actions]

This pull request has been automatically locked since there hasn't been any recent activity after it was closed. Please open a new issue for related bugs.

Looking for a help forum? We recommend joining the Amplify Community Discord server *-help channels or Discussions for those types of questions.