<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 4/4/23 21:53, George Joseph wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAP=uFEuUPW4wF5+06LYYfzR8b912Zbh-VMRsmdLqOqNR=9H=-A@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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>
      </div>
    </blockquote>
    <p>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.<br>
    </p>
    <p>The Gopherbot seen <a moz-do-not-send="true"
        href="https://github.com/golang/go/issues/59450">here</a> for
      example is adding tags and mentions to related issues. And <a
        moz-do-not-send="true"
        href="https://github.com/golang/go/pull/59301">this pull request</a>
      was automatically imported into Gerrit for code review and closed
      after being successfully merged. Source of this bot can be found
      here: <a class="moz-txt-link-freetext" href="https://github.com/golang/build/tree/master/cmd/gopherbot">https://github.com/golang/build/tree/master/cmd/gopherbot</a><br>
    </p>
    <p>References:<br>
<a class="moz-txt-link-freetext" href="https://docs.github.com/en/apps/creating-github-apps/creating-github-apps/about-apps">https://docs.github.com/en/apps/creating-github-apps/creating-github-apps/about-apps</a><br>
      <a class="moz-txt-link-freetext" href="https://docs.github.com/en/rest?apiVersion=2022-11-28">https://docs.github.com/en/rest?apiVersion=2022-11-28</a><br>
      <a class="moz-txt-link-freetext" href="https://github.com/marketplace">https://github.com/marketplace</a><br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Dennis Buteyn
Xorcom Ltd</pre>
  </body>
</html>