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

[George Joseph]

On Wed, Apr 5, 2023 at 2:19 AM Dennis Buteyn 
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  for
> example is adding tags and mentions to related issues. And this pull
> request  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
-- 
_
-- 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

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

[George Joseph]

On Tue, Apr 4, 2023 at 3:03 PM Joshua C. Colp  wrote:

> On Tue, Apr 4, 2023 at 5:27 PM George Joseph  wrote:
>
>>
>>
>> On Tue, Apr 4, 2023 at 1:16 PM  wrote:
>>
>>> On 4/4/2023 2:53 PM, George Joseph wrote:
>>> > 
>>> >
>>> > 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.
>>> Thanks, George, et al, for all this amazing work. I admit Gerrit has
>>> grown on me a little over the years, but other developers I've discussed
>>> with do prefer GitHub and I'm eager to give this a try when it's all
>>> ready.
>>>
>>> One question from looking through some of the workflows that are up now:
>>>
>>> https://github.com/asterisk/asterisk-gh-test/blob/master/.github/workflows/CloseStaleIssues.yml
>>>
>>> I'm a bit curious about the auto-closing functionality:
>>>
>>
>>>   * Do you think 14-21 days is a sufficient threshold for most issues?
>>> It seems potentially a bit low to me. For example, once an issue is
>>> triaged and opened, will it just be closed automatically 3 weeks
>>> later if it hasn't been resolved by then? Or are issues in the
>>> 'open' state exempt from this, this is purely for triage to weed out
>>> junk issues?
>>>
>>   * Case in point: one vendor I deal with frequently has this annoying
>>> auto-close functionality in their system which triggers after about
>>> 2 weeks or so. Often more time is required on one of our ends just
>>> to follow up on the last thing, so there is a lot of inevitable
>>> "commenting to avoid auto closure" and this just adds a lot of noise
>>> into the tickets.
>>>   * Is there any connection with reviews/PRs in progress? Suppose an
>>> issue is open and maybe on the verge of being stale, but someone has
>>> submitted a PR against. Changes can often take much longer than 3
>>> weeks to merge, so it wouldn't make sense for an issue to close
>>> itself in that case. So I'm concerned perhaps that might not be
>>> sufficient time.
>>>
>>
>> We're still thinking about the issues process but...
>>
>> The action allows you to specify labels that make an issue exempt from
>> auto-closure.  I was thinking that when a PR gets submitted, we'd look for
>> the "Resolves: #issuenum" tag in the commit message, then add an
>> "InProgress" label to the issue to prevent it from being auto closed.  The
>> issue would then get closed when the PR is closed.
>>
>> I'm also thinking it would only close issues that have been inactive and
>> assigned to the submitter.  Like the "Waiting for Feedback" status in Jira.
>>
>> Does that make sense?
>>
>
> I think issues should only be closed if we are waiting for feedback from
> the reporter during the triage process. Once accepted the issue should
> remain open until either automatically closed through PR, or someone else
> closes it. Same as now.
>
> Ack.



> --
> Joshua C. Colp
> Asterisk Project Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _
> -- 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
-- 
_
-- 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

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

[Dennis Buteyn]

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  for 
example is adding tags and mentions to related issues. And this pull 
request  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

--
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

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

[Joshua C. Colp]

On Tue, Apr 4, 2023 at 5:27 PM George Joseph  wrote:

>
>
> On Tue, Apr 4, 2023 at 1:16 PM  wrote:
>
>> On 4/4/2023 2:53 PM, George Joseph wrote:
>> > 
>> >
>> > 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.
>> Thanks, George, et al, for all this amazing work. I admit Gerrit has
>> grown on me a little over the years, but other developers I've discussed
>> with do prefer GitHub and I'm eager to give this a try when it's all
>> ready.
>>
>> One question from looking through some of the workflows that are up now:
>>
>> https://github.com/asterisk/asterisk-gh-test/blob/master/.github/workflows/CloseStaleIssues.yml
>>
>> I'm a bit curious about the auto-closing functionality:
>>
>
>>   * Do you think 14-21 days is a sufficient threshold for most issues?
>> It seems potentially a bit low to me. For example, once an issue is
>> triaged and opened, will it just be closed automatically 3 weeks
>> later if it hasn't been resolved by then? Or are issues in the
>> 'open' state exempt from this, this is purely for triage to weed out
>> junk issues?
>>
>   * Case in point: one vendor I deal with frequently has this annoying
>> auto-close functionality in their system which triggers after about
>> 2 weeks or so. Often more time is required on one of our ends just
>> to follow up on the last thing, so there is a lot of inevitable
>> "commenting to avoid auto closure" and this just adds a lot of noise
>> into the tickets.
>>   * Is there any connection with reviews/PRs in progress? Suppose an
>> issue is open and maybe on the verge of being stale, but someone has
>> submitted a PR against. Changes can often take much longer than 3
>> weeks to merge, so it wouldn't make sense for an issue to close
>> itself in that case. So I'm concerned perhaps that might not be
>> sufficient time.
>>
>
> We're still thinking about the issues process but...
>
> The action allows you to specify labels that make an issue exempt from
> auto-closure.  I was thinking that when a PR gets submitted, we'd look for
> the "Resolves: #issuenum" tag in the commit message, then add an
> "InProgress" label to the issue to prevent it from being auto closed.  The
> issue would then get closed when the PR is closed.
>
> I'm also thinking it would only close issues that have been inactive and
> assigned to the submitter.  Like the "Waiting for Feedback" status in Jira.
>
> Does that make sense?
>

I think issues should only be closed if we are waiting for feedback from
the reporter during the triage process. Once accepted the issue should
remain open until either automatically closed through PR, or someone else
closes it. Same as now.

-- 
Joshua C. Colp
Asterisk Project Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- 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

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

[asterisk]

On 4/4/2023 4:26 PM, George Joseph wrote:

On Tue, Apr 4, 2023 at 1:16 PM  wrote:


On 4/4/2023 2:53 PM, George Joseph wrote:




   * Is there any connection with reviews/PRs in progress? Suppose an
 issue is open and maybe on the verge of being stale, but someone has
 submitted a PR against. Changes can often take much longer than 3
 weeks to merge, so it wouldn't make sense for an issue to close
 itself in that case. So I'm concerned perhaps that might not be
 sufficient time.


We're still thinking about the issues process but...

The action allows you to specify labels that make an issue exempt from
auto-closure.  I was thinking that when a PR gets submitted, we'd look for
the "Resolves: #issuenum" tag in the commit message, then add an
"InProgress" label to the issue to prevent it from being auto closed.  The
issue would then get closed when the PR is closed.

I'm also thinking it would only close issues that have been inactive and
assigned to the submitter.  Like the "Waiting for Feedback" status in Jira.

Does that make sense?
That makes sense, that seems like it would replicate the current 
behavior pretty nicely.

Thanks, George!

--
_
-- 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

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

[George Joseph]

On Tue, Apr 4, 2023 at 1:16 PM  wrote:

> On 4/4/2023 2:53 PM, George Joseph wrote:
> > 
> >
> > 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.
> Thanks, George, et al, for all this amazing work. I admit Gerrit has
> grown on me a little over the years, but other developers I've discussed
> with do prefer GitHub and I'm eager to give this a try when it's all ready.
>
> One question from looking through some of the workflows that are up now:
>
> https://github.com/asterisk/asterisk-gh-test/blob/master/.github/workflows/CloseStaleIssues.yml
>
> I'm a bit curious about the auto-closing functionality:
>

>   * Do you think 14-21 days is a sufficient threshold for most issues?
> It seems potentially a bit low to me. For example, once an issue is
> triaged and opened, will it just be closed automatically 3 weeks
> later if it hasn't been resolved by then? Or are issues in the
> 'open' state exempt from this, this is purely for triage to weed out
> junk issues?
>
  * Case in point: one vendor I deal with frequently has this annoying
> auto-close functionality in their system which triggers after about
> 2 weeks or so. Often more time is required on one of our ends just
> to follow up on the last thing, so there is a lot of inevitable
> "commenting to avoid auto closure" and this just adds a lot of noise
> into the tickets.
>   * Is there any connection with reviews/PRs in progress? Suppose an
> issue is open and maybe on the verge of being stale, but someone has
> submitted a PR against. Changes can often take much longer than 3
> weeks to merge, so it wouldn't make sense for an issue to close
> itself in that case. So I'm concerned perhaps that might not be
> sufficient time.
>

We're still thinking about the issues process but...

The action allows you to specify labels that make an issue exempt from
auto-closure.  I was thinking that when a PR gets submitted, we'd look for
the "Resolves: #issuenum" tag in the commit message, then add an
"InProgress" label to the issue to prevent it from being auto closed.  The
issue would then get closed when the PR is closed.

I'm also thinking it would only close issues that have been inactive and
assigned to the submitter.  Like the "Waiting for Feedback" status in Jira.

Does that make sense?



>
> I guess this will answer itself after the migration when we see how
> people interact with it, but curious if these were just defaults or if
> these were customized for the project.
>
> Thanks again for all this heavy lifting!
>
>   NA
>
>
-- 
_
-- 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

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

[asterisk]

On 4/4/2023 2:53 PM, George Joseph wrote:



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.
Thanks, George, et al, for all this amazing work. I admit Gerrit has 
grown on me a little over the years, but other developers I've discussed 
with do prefer GitHub and I'm eager to give this a try when it's all ready.


One question from looking through some of the workflows that are up now:
https://github.com/asterisk/asterisk-gh-test/blob/master/.github/workflows/CloseStaleIssues.yml

I'm a bit curious about the auto-closing functionality:

 * Do you think 14-21 days is a sufficient threshold for most issues?
   It seems potentially a bit low to me. For example, once an issue is
   triaged and opened, will it just be closed automatically 3 weeks
   later if it hasn't been resolved by then? Or are issues in the
   'open' state exempt from this, this is purely for triage to weed out
   junk issues?
 * Case in point: one vendor I deal with frequently has this annoying
   auto-close functionality in their system which triggers after about
   2 weeks or so. Often more time is required on one of our ends just
   to follow up on the last thing, so there is a lot of inevitable
   "commenting to avoid auto closure" and this just adds a lot of noise
   into the tickets.
 * Is there any connection with reviews/PRs in progress? Suppose an
   issue is open and maybe on the verge of being stale, but someone has
   submitted a PR against. Changes can often take much longer than 3
   weeks to merge, so it wouldn't make sense for an issue to close
   itself in that case. So I'm concerned perhaps that might not be
   sufficient time.

I guess this will answer itself after the migration when we see how 
people interact with it, but curious if these were just defaults or if 
these were customized for the project.


Thanks again for all this heavy lifting!

 NA


--
_
-- 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