Updates to new script needs more testing when configured on GHES

[ppremk]

@parkerbxyz.. :wave-smile: .. so we spent some time setting up GHES customer with the new script fro the training manual..there are some edge cases we need to fix and test again..

• add collaborators - if commenters are already org members.. they are not added as collaborators
• continue from the above, when running the (conflict and games script) since they are not added as collaborator and it start iterating through all team members in the org and creates a repo for every member
• Depending on the Org Level Repo creation policy, the script has issues when trying to create public repo - the new caption-this repo

I have not been able to allocate time to dive into the scripts to pair program with you.. im just adding this as a reference and discussion point when we find time to fix it..

Also note that the scripts are on customer GHES and they have some strict policy. That could also be messing up the scripts.. so maybe these can be a one off edge case

[amyschoen]

@ppremk, the first two bullets are related and very likely the result of the changes I made. I should be able to test behavior and potential fixes in GHES. As for the third bullet, they're going to need to use a token that has the rights to create repos. There's no way I can think of otherwise to work around that one.

[ppremk]

Hi @amyschoen noted on the changes for the first two bullets, I have not got the bandwidth to jump in and test those scenarios this week. For the third bullet point, we used a token with all scopes turned on. It was an Enterprise Level policy that was set by Enterprise Admin which only allows members to create an Internal repo. We enabled the create Public repo option via the Org Owner and it was able to run as expected. We will need to test this again to be sure on our end 🙂 Let's stay in touch async.

[amyschoen]

Oh interesting. We really haven't started using internal yet. This might be super easy to do. I see two possible options:

1. We could try to create the repo and if that fails, we can have a fallback that creates the repo as internal.

2. We could add something to the initial .trainingrc file that sets a preference for public vs internal and use that throughout.

I'm leaning towards the second option. What do you think @ppremk?

[ppremk]

Hey @amyschoen 🙂 I would like to understand how the Org/Enterprise level Repo creation policy together with member privileges and githubteacher PAT token scope work in combination before deciding on a solution. The reason for this is because the above configuration provides a matrix of option on how customers setup their GHES, and we need to find a sweet spot which satisfies a criteria that works in our favour.

From the option presented above, I too lean towards the second option as a short term fix @amyschoen

[amyschoen]

The tokens are going to maximally have the permissions of the account that was used to create them, but you can give it less privileges. If you wanted to work around the policy, then you'd likely need a token for a user with site admin. That would be very dangerous. I do have a test GHES instance, but it's currently in use. I wouldn't be able to play around with this part without potentially breaking things to others until near the end of the month when the other effort wraps up.

[ppremk]

noted. The token we used was from an Org Owner and even that failed. We will align internally on this and circle back. Thanks again @amyschoen ❤️

[amyschoen]

You're welcome. Let me know what you find out. I'm curious how this impacts things in case we change up our permissions model in the future.