Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added enhancement Sync settings after installing the integration #74

Closed
wants to merge 9 commits into from
Closed

Conversation

knrt10
Copy link

@knrt10 knrt10 commented Mar 19, 2018

This is reference to issue #1

Added Functionalities:

When a user has a predefined .github folder and they install the probot/settings app after that, then 2 functionalities are added

1.) If .github folder has settings.yml file then it will be automatically synced.

2.) If no settings.yml file is found in .github then the bot opens a PR with some default settings in settings.yml file.

3.) When PR is merged bot automatically delete the branch created by bot.

@knrt10 knrt10 changed the title Added enahancement Sync settings after installing the integration Added enanhacement Sync settings after installing the integration Mar 19, 2018
@knrt10 knrt10 changed the title Added enanhacement Sync settings after installing the integration Added enhancement Sync settings after installing the integration Mar 19, 2018
@jwsloan
Copy link
Collaborator

jwsloan commented Mar 21, 2018

Thanks for working on this! Cool idea!
A concern I have... If I don't like every default setting this provides, then the PR is of no use, correct? What if it actually grabbed the current settings for that repo, and put in a PR creating a matching settings.yml file?

@knrt10
Copy link
Author

knrt10 commented Mar 21, 2018

@jwsloan Yea this is nice idea. I will implement this and update the PR.

@jwsloan
Copy link
Collaborator

jwsloan commented Mar 21, 2018

Now that I think about it some more, I think this will need to involve creating importers for each of the current plugins. The ones that exist now could be moved into an exporters file. Then you could look through each setting as it is, and pass those settings to the appropriate importer similar to the way the current plugins work from the settings file.

@knrt10
Copy link
Author

knrt10 commented Mar 21, 2018

@jwsloan I implemented that

A concern I have... If I don't like every default setting this provides, then the PR is of no use, correct? What if it actually grabbed the current settings for that repo, and put in a PR creating a matching settings.yml file?

But I did'nt get this part

Now that I think about it some more, I think this will need to involve creating importers for each of the current plugins. The ones that exist now could be moved into an exporters file. Then you could look through each setting as it is, and pass those settings to the appropriate importer similar to the way the current plugins work from the settings file.

Would you please explain?
Thanks in advance.

@jwsloan
Copy link
Collaborator

jwsloan commented Mar 22, 2018

@knrt10
The current functionality can be thought of as exporting the settings from the yml file to the actual repo settings. It has been implemented as separate plugins corresponding to API endpoints. This could have been done as one large file that updates all the things, but that was not the design decision. Each plugin only knows about one area to export settings for.

Hopefully that first part makes sense.

The new functionality this issue describes could be looked at the same way, only in reverse. Each end point that is represented in the settings file would have a specific importer js file. Of course, that would make actually writing out the yml file a bit interesting.

I could be totally wrong. And terrible at explaining it. Does it make any more sense now?

@patcon
Copy link

patcon commented Apr 5, 2018

It seems like this might be working as submitted 🎉

I totally get where you're coming from @jwsloan, but in the interest of supporting a first-time contributor in getting to a successful merge (woooo party yeah!), could we move that import/export architecture enhancement into a new ticket? I feel like you've provided an awesome description that really tees it up for the next person, if we were to copy that over?

@jwsloan
Copy link
Collaborator

jwsloan commented Apr 5, 2018

That's a good call, @patcon. It would be great if we could get #76 merged first, and then include the branch protection settings in this. It could lock down master, required Code Owner approval by default.

@aryannarora
Copy link

aryannarora commented Apr 6, 2018

@knrt10 Great PR!! 🎉
One question though, why did we have to create our own encode function?

EDIT: Sorry, if it's a rookie one. 😆

@patcon
Copy link

patcon commented Apr 7, 2018

TWINS! Had the same thought, but felt like I should research before asking :) But that was prob my ego speaking..!

@knrt10
Copy link
Author

knrt10 commented Apr 7, 2018

@aryannarora @patcon Thanks. Whenever we want to create a github file using API our file contents should be base64 encoded as per API specifications and also when we receive contents of a repo its encoded so we need to decode it, and I could not find any packages so wrote the function for both encoding and decoding. This PR is using the encoding part and #77 is using both. Hope this helps. ✌️ .

index.js Outdated
' permission: push'

const base64 = require('./encode')
const encodedString = base64.encode(string)
Copy link
Contributor

@JasonEtco JasonEtco Apr 7, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@knrt10 instead of using some custom created Base64 encoding, you can use Node.JS's built-in Buffer global:

const encodedString = Buffer.from(string).toString('base64')

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok let me update both the changes

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@knrt10 i was asking about this only.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aryannarora finally changed it.

index.js Outdated
const getRepo = await context.github.repos.get({owner: owner, repo: repoName})
await context.github.gitdata.createReference({owner: owner, repo: repoName, ref: 'refs/heads/probot', sha: sha})
// setting the template of file
const string = 'repository: \n' +
Copy link
Contributor

@JasonEtco JasonEtco Apr 7, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please move this into a separate file? It'd also be good to use a template literal to avoid all of the \n characters. In the separate file, you can do:

module.exports = getRepo => `
  name: ${getRepo.data.name}
`

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ooooo... I am not too proud to admit that I just learned a thing. Thanks! 🎉

@knrt10
Copy link
Author

knrt10 commented Apr 7, 2018

@JasonEtco changed the files as you asked. Please have a look.

@itaditya
Copy link

@knrt10 I checked that you are listening to installation_repositories.added event for syncing the .github/settings.yml file. However this event doesn't trigger when you install the app for the first time.

So if a user has no .github/settings.yml present and installs the app for the first time on his account, then no PR will be made as of now.

@knrt10
Copy link
Author

knrt10 commented Apr 19, 2018

@itaditya Thanks. Let me update that too.

@itaditya
Copy link

itaditya commented Apr 19, 2018

Copy link

@itaditya itaditya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Listen to installation event also

@stale
Copy link

stale bot commented Jul 21, 2018

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

@stale stale bot added the wontfix label Jul 21, 2018
@knrt10
Copy link
Author

knrt10 commented Jul 21, 2018

yep still relevant

@stale stale bot removed the wontfix label Jul 21, 2018
@nesl247
Copy link

nesl247 commented Aug 7, 2018

Any update on this?

@stale
Copy link

stale bot commented Nov 5, 2018

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

@stale stale bot added the wontfix label Nov 5, 2018
@knrt10
Copy link
Author

knrt10 commented Nov 6, 2018

yep relevant

@stale stale bot removed the wontfix label Nov 6, 2018
@stale
Copy link

stale bot commented Feb 4, 2019

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

@stale stale bot added the wontfix label Feb 4, 2019
@knrt10
Copy link
Author

knrt10 commented Feb 4, 2019

Not at all relevant.

@knrt10 knrt10 closed this Feb 4, 2019
@patcon
Copy link

patcon commented Feb 4, 2019

Just to check in @knrt10 (I'm way out of the loop on the settings plugin, though have recommended it around) -- is this actually irrelevant, or was there frustration involved in getting it merged?

I really appreciating what it added way back when I bug-tested it, so am confused why it stayed in limbo :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants