<div dir="ltr"><div>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.</div><div><ol><li>Very few GitHub projects have multiple simultaneous release branches as we do and GitHub has no built-in cherry-picking functionality.</li><li>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.</li><li>Some of the automations we need, like simply reporting test completion status on the PR, require write access to the PR.</li><li>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...</li><li>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.</li><li>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...</li><li>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.</li></ol><div>That's just some of the background that's driving the process and development of the workflows.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div><div dir="ltr" data-smartmail="gmail_signature"></div></div></div></div>