Better contributor experience: no CI/CD failures

[noahtalerman]

• @noahtalerman: User requested this because they submitted a PR for a new Fleet-maintained app from their fork of Fleet. Fleet's CI/CD fails if the PR is from a fork. How do I resolve this as a contributor?
  • More: when a contributor submitted the PR there were a bunch of GH actions failures (contributor getting spammed about it). just want to confirm, i don't think there's anything we can do about this? it looked like the failures were related to 'requiring a username and password', but he's not a part of our GH org.
• @noahtalerman: Also, have Docker publish work for contributor PRs from forks so we don't have to create a copy branch, like this one, to test new apps: https://github.com/fleetdm/fleet/pull/29084
• @noahtalerman: Also token is confusing. We could rename it to something like homebrew_id:

[iansltx]

If the scope on this is just for Fleet-maintained apps, #29177 is a significantly smaller lift to get to the same destination, as making that change will allow Fleet-maintained app adds to only affect ee/maintained_apps, which gets all work out of the way of our CI pipelines that would normally fail. Additionally, that'll allow end-to-end testing (including icon) with an existing version of Fleet server, rather than needing to build/publish a branch-based Docker tag.

At which point "CI is red on every contributor commit due to access control issues" can be addressed in a separate (potentially eng-init) issue, as getting that workflow right probably requires not running a number of CI jobs on contributor PRs. The solution there is likely to turn off a number of those jobs when run from a contributor PR, as the alternative effectively allows external contributors push access to our Docker Hub and Quay accounts, which...is a security issue.