[asterisk-dev] GitHub: Side Note: What makes us "special"?

[George Joseph]

Every open source project, CI/CD system and SCM system has its own quirks.
Asterisk and GitHub are no exception. :)    Here's some background, most of
which is just informational for you but caused us some head scratching and
will probably continue to do so.

   1. Very few GitHub projects have multiple simultaneous release branches
   as we do and GitHub has no built-in cherry-picking functionality.
   2. For very valid security reasons, GitHub limits the permissions of
   workflows triggered by PRs submitted from forked repositories to
   read-only.  Otherwise anyone could fork the Asterisk repo and submit a pull
   request that changes the workflow that's about to run for thiat PR.   OK,
   it's not quite as easy as that but it is a concern.
   3. Some of the automations we need, like simply reporting
   test completion status on the PR, require write access to the PR.
   4. We could add Asterisk community developers as collaborators to the
   repos which would give them additional permissions but that becomes an
   administrative overhead for the core team.  Besides...
   5. GitHub's most restrictive level of collaborator access (Triager)
   allows a user to manipulate the PRs and issues belonging to other users
   which is probably not a good idea.
   6. You know how you can add a "regate" or "recheck" comment to Gerrit
   today and have Jenkins re-run the tests?  Well, GitHub doesn't need that
   because it has the ability to re-run jobs right from the UI.  However, when
   we were thinking about the cherry-pick process we thought we could trigger
   it using the same mechanism...just add the comment and the process would
   kick off.  Unfortunately, unlike Gerrit/Jenkins, if you have a job trigger
   on a comment, it'll trigger on EVERY comment even if the keyword isn't
   present in it.  That's just a waste of resources and it would flood the job
   history with crap.  Then we thought...
   7. In my earlier email I mentioned an Asterisk core team member having
   to add a label to kick off the cherry-pick process.  Well, that started
   with "Let's have the user add labels to kick the cherry-pick process off".
   Except...  A user who is not a member of the organization can't add labels
   even to their own PRs and issues.

That's just some of the background that's driving the process and
development of the workflows.

Speaking of workflows...  If you want to see the workflows and
actions we've written so far, check out the asterisk/asterisk-gh-test (the
.github/workflows directory) and asterisk/asterisk-ci-actions repos.   If
you're experienced with GitHub workflows, feedback is appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20230404/4e1d8800/attachment.html>