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

[George Joseph]

On Wed, Apr 5, 2023 at 2:19 AM Dennis Buteyn <dennis.buteyn at xorcom.com>
wrote:

> On 4/4/23 21:53, George Joseph wrote:
>
> 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.
>
> I've noticed quite a few GitHub projects use bots aka apps to perform a
> variety of tasks such as automatic tagging, triggering builds, adding test
> results and so forth. GitHub provides a fairly rich API which should cover
> most of the issues mentioned. Aside from the usual automation, I've also
> seen bots perform specific actions by writing instructions as comments.
> Hundreds of existing apps can be found on the GitHub marketplace, which
> should give some ideas as to what can or cannot be done.
>
> The Gopherbot seen here <https://github.com/golang/go/issues/59450> for
> example is adding tags and mentions to related issues. And this pull
> request <https://github.com/golang/go/pull/59301> was automatically
> imported into Gerrit for code review and closed after being successfully
> merged. Source of this bot can be found here:
> https://github.com/golang/build/tree/master/cmd/gopherbot
>
> References:
>
> https://docs.github.com/en/apps/creating-github-apps/creating-github-apps/about-apps
> https://docs.github.com/en/rest?apiVersion=2022-11-28
> https://github.com/marketplace
>
> Yeah apps are certainly more powerful but they have to run somewhere and
we were trying to avoid having to add an AWS, gcloud, Azure, etc.
component to the process, at least at first.  We'll keep it in mind though
and if we find a situation where something we really want/need to do can
only be done with an app, we'll reconsider.




> --
> Dennis Buteyn
> Xorcom Ltd
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20230405/a9fe9a27/attachment.html>