If a project or label is not specified within the settings.yml, but they do exist on the repository already, then the probot will automatically delete everything which doesn't exist within the settings.yml.

I'd like the ability to configure whether things get deleted if they aren't present in the settings.yml

I noticed the current documentation points out the security issue of push-access users effectively getting admin via this application.

One suggestion that might be worth adding to the documentation is setting admins as the code owner of the yaml file, and then selecting the option to require code-owner review for the repository. It allows others to suggest changes via pull-request, but an admin still has to approve it. Not the most dynamic solution (requires update separate from the permissions), but it's something.

If the team things this is worth doing, I'd be happy to put together a pull request (either to add to the main readme or add a separate markdown file like deploy.md to link to from the main one)

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml
• The new Node.js version is in-range for the engines in 1 of your package.json files, so that was left alone

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

Errors are silently ignored and end-users have no idea why it's not working.

Options:

1. If .github/settings.yml is changed in a pull request, a status can be set
2. If it's changed outside of a pull request, open an issue in the repo

In order to account for consolidating multiple label names into a single label, the oldname key should accept a list of labels which will be renamed.

  - name: first-timers-only
    # include the old name to rename an existing label
    oldname: ["Help Wanted", "help-wanted", "needs-some-help", "help-me-out-here"]

with the branch protection plugin now available in production, i gave it a shot but havent had luck. i originally made the comment below on the PR for getting the plugin integrated, but i'm moving this to its own issue to track this more clearly.

i don't really have more detail beyond what i linked to below, but i'm happy to try other variations to help track down any issues.

unfortunately, i'm not seeing this setting take effect.

i initially tried just setting what i hoped would be the minimum. when that didn't work, i paid more attention to the "Required" properties. since that didn't enable protection for the branch either, i tried enabling one of the rules i didnt need, just to see if more was necessary, but still had no luck. am i missing something obvious?

also, just a side note, but the new required properties somewhat conflict with the note under Usage that states:
All settings are optional.

I realize that they are only required if the higher-level settings are provided, but some clarification might be valuable there.

If a repository already has a .github/config.yml, then the settings should be synced when the integration is installed.

This involves listening to the integration webhook events and then looking for a .github/settings.yml in all repositories that the installation is given access to.

Our team was hoping to make use of the opt-out pattern advertised by probot-config (https://github.com/probot/probot-config#an-opt-out-pattern). That isn't currently possible because probot-settings requires that the .github/settings.yml file in each repo be changed to sync settings. Could probot-settings be updated with an environment variable that would allow sync on all changes to master, not just on changes to that one file?

I had the settings app enabled on my one repo (and then globally, just to be sure), and pushing updates didn't seem to have any effect. Am I doing this right?

https://github.com/patcon/sample-civictech-app

I'm confused to what reason the app asks for:

• "write access to code"
• "Read and write access to administration, commit statuses, issues, repository projects, and single file"

I'm assuming the "single file" in question here is .github/settings.yml`

write access shouldn't be needed from the currently exposed functionality?

If the label color code consists of leading zeros, in some cases it will take it as an integer and it will truncate the leading zeros which leads to following error.

Suggest solution,

Hi again!

I'm seeing the ability to delete/remove labels in settings/lib/plugins/labels.js, but am I correct in finding that it hasn't been implemented yet?

It seems fairly niche, but for creating starter project templates for tech and GitHub beginners, it would be nice to clean-up the default GitHub labels to make things as clear as possible, in case they don't suit a project type :)

Any preference on how this might be done? My first inclination is to allow this would be to allow one of these:

# option A
labels:
  - name: wontfix
    delete: true

# option B
labels:
  - deletename: wontfix

# option C
labels:
  - oldname: wontfix

Before I jump in, can anyone offer advice on:

• What's possible with current arch?
• Are any of the above are good or bad patterns?

Thanks!

The documentation for the team management states:

NOTE: The APIs needed for teams are not supported yet by GitHub Apps
https://developer.github.com/v3/apps/available-endpoints/

however the official GitHub API documentation states:

The following endpoints are available for use by GitHub Apps. Your app can make the following requests using GraphQL v4 or REST v3 endpoints. For more information, see "GitHub Apps."

so perhaps the APIs got updated? and all that's missing to making this work is the preview headers addition?

unless I'm missing something, I'm happy to make a PR to add preview headers.

cheers.

Because when we have the hash sign and some plugin on the IDE, you get the color visually.

I walked through all the setup to get this bot up and running, but when I created the integration I get this not very helpful error when trying to setup the Repository Contents Hook:

Also, the README should note that the Private Key is needed for tests or it needs to be mocked ;)

See API docs on creating a hook.

The only limitation with configuring hooks via a file in the repository is that secret can't be defined here.

Similar to collaborators, the config might look something like this:

teams:
  - name: engineers
    permission: admin
  - name: project-managers
    permission: push
  - name: bosses
    permission: pull

Low priority but would be nice to get better error messages/validation when a key is mistyped.

Example config

lables:
  - name: bug
    color: CC0000

Accidentally mis-spelling labels as lables will cause a Plugin is not a contructor error.

2019-02-14T18:29:24.357037+00:00 app[web.1]: 18:29:24.356Z ERROR event: Plugin is not a constructor (id=734cd71c-3086-11e9-8c64-6facabd86ce3)
2019-02-14T18:29:24.357071+00:00 app[web.1]:   TypeError: Plugin is not a constructor
2019-02-14T18:29:24.357079+00:00 app[web.1]: at Promise.all.Object.entries.map (/app/node_modules/probot-settings/lib/settings.js:24:14)
2019-02-14T18:29:24.357082+00:00 app[web.1]: at Array.map (<anonymous>)
2019-02-14T18:29:24.357084+00:00 app[web.1]: at Settings.update (/app/node_modules/probot-settings/lib/settings.js:19:52)
2019-02-14T18:29:24.357086+00:00 app[web.1]: at github.repos.getContent.then.res (/app/node_modules/probot-settings/lib/settings.js:8:49)
2019-02-14T18:29:24.357089+00:00 app[web.1]: at process._tickCallback (internal/process/next_tick.js:68:7)

It took me digging into the code to see what the issue was. Definitely user error but it would be helpful to handle this specific case with a better log message, e.g. key 'foo' is not supported or whatnot.

The description on installation page still shows old probot/configurer. (GtiHub account > Seetings > Applications > Setings > Configure)
Shouldn't be probot/settings ? 😺

If a setting is changed via the GItHub UI, the config file should be updated.

It should be relatively straight forward to listen for webhook events that could affect the config file (.e.g. description edited, collaborator added, label created, etc) and update the configuration file. Ideally, this service would update the config in a branch and open a pull request with the changes.

When managing a project that has a lot of similar repositories, it would be helpful to have one repository with defaults that other repositories inherit from.

How it would work:

1. Create a repository named default, which has templates and a config for new repositories
2. When a new repository is created, it will automatically open a pull request that copies over the templates, one of which would be a .github/config.yml with an option that tells it to inherit from the default
3. Any future changes to the config in the default repository would be synced to repositories that inherit from it

@claudiopro pointed out via twitter that this integration inherently escalates anyone with push permissions to admin, since they can push config settings.

First, this should be clearly stated in the README and integration page.

Eventually, it might be nice to have a feature that only allow changes to the config file to be merged by specific people/teams, or those with admin access (via a combination of protected branches, required statuses, and branch restrictions).

I keep making changes and push, but nothing changes.

It would be great to see the ability to add collaborators to a team. For example, when we would add new folks to the repo, it would be great to add them to a corresponding team so you can "@" mention them... like @-maintainers etc etc

Hiya! I imagine this might be out of scope, either technically or on principle. Only asking because in my mind, probot/settings is also a way to bootstrap new projects with a bunch of presets (like Heroku's app.json allows). If that's your aspiration as well, then it might be worth a discussion :)

Thanks!

I don't see an existing discussion on this, so here we are.

I'd like to gather some thoughts on how this bot could include support for managing repository webhooks.

There's the tricky issue with not treading on webhooks that are already managed by other applications, e.g. CircleCI or Snyk.

Basic use case I'm interested in is insuring that a webhook is installed on many repositories via shared configuration in the .github repository.

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.

Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.

If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.

We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

Once you have installed CI on this repository, you’ll need to re-trigger Greenkeeper’s initial Pull Request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper integration’s white list on Github. You'll find this list on your repo or organiszation’s settings page, under Installed GitHub Apps.

Description

When using extend of a settings files that extends yet another settings file, the entirely functionality breaks.

Steps to replicate

Repository A

• Probot settings works fine here

repository:
  allow_squash_merge: true
  allow_merge_commit: false
  allow_rebase_merge: true

Repository B

• Probot settings works fine here

_extends: repository-a
repository:
  allow_rebase_merge: false

Repository C

• Probot settings stops working in this repository

_extends: repository-b
repository:
  description: "Repository C"

See API docs for creating a milestone

https://github.com/probot/settings/blob/80a5043bf748ba6ff3a5e47ce0a26b20c2bcf21e/index.js#L13

const settingsModified = payload.commits.find(commit => {
      return commit.added.includes(Settings.FILE_NAME) ||
        commit.modified.includes(Settings.FILE_NAME)
    })

settingsModified is returning undefined.

Didn't seem to work here: edgi-govdata-archiving/edgi-scripts@b311b73

It would be great to implement support for probot-config. This would enable organization administrators to enforce a number of default repository settings across their org.

Re-ticketed from #74 (comment)

Thanks @jwsloan! cc @knrt10

The current .github/config.yml is very specific to this app. Package managers often include some of the relevant fields (e.g. description, authors), so it'd be great to add support for fetching as much data as possible from NPM, RubyGems, etc.

Hi, nice idea!

We, at LambdaBooks, often use the same labels in our repos. I'm trying to use github-configurer for making these labels portable from one repo to another.

I set up an integration and created a .github/config.yml file. Unfortunately, this doesn't work and I have no idea why.

I've made a small test. As you may see, here is a has_wiki option set to false, but actually repo still has a Wiki page.

Maybe I'm missing something? Could anybody help me?

app.json is a manifest format for describing web apps. It declares environment variables, add-ons, and other information required to run an app on Heroku. This document describes the schema in detail.

–Heroku Dev Center

It has description and website, and the keywords could become topics.

https://github.com/blog/2505-label-improvements-emoji-descriptions-and-more

Emoji -When words are just not enough, include emoji in your labels to express yourself and the needs of your project through tiny images. ✨

Descriptions - Add descriptions to your labels to provide even more context and help your contributors apply the right ones to their issues or pull requests. Descriptions will appear when you hover your mouse over labels around GitHub.

Please add the probot-apptopic. See probot/probot.github.io#40 for details.

It would be neat if my .github/config file could inherit from a remote URL, such that I could have some centralized config shared amongst repos, with some local overrides.

Re-ticketed from #83 (comment)

Would this be a good idea?

Pushing a package.json that looks like this:

{
  "name": "probot-combo-value-pack",
  "private": true,
  "dependencies": {
    "probot-settings": "probot/settings",
    "probot-labeler": "probot/autolabeler"
  },
  "scripts": {
    "start": "probot run"
  },
  "engines": {
    "node": "10.x"
  },
  "probot": {
    "apps": [
      "probot-settings",
      "probot-labeler"
    ]
  }
}

and getting an error within probot-config, which says context.github.repos.getContents is not a function:

2019-05-31T09:17:27.970-05:00 [APP/PROC/WEB/1] [OUT] at EventEmitter.events.on (/home/vcap/deps/0/node_modules/probot/lib/robot.js:102:17)
2019-05-31T09:17:27.970-05:00 [APP/PROC/WEB/1] [OUT] at robot.on (/home/vcap/deps/0/node_modules/probot-settings/index.js:9:26)
2019-05-31T09:17:27.970-05:00 [APP/PROC/WEB/1] [OUT] at getConfig (/home/vcap/deps/0/node_modules/probot-config/lib/index.js:114:24)
2019-05-31T09:17:27.970-05:00 [APP/PROC/WEB/1] [OUT] at loadYaml (/home/vcap/deps/0/node_modules/probot-config/lib/index.js:48:49)
2019-05-31T09:17:27.970-05:00 [APP/PROC/WEB/1] [OUT] �[90m TypeError: context.github.repos.getContents is not a function

Using GitHub Enterprise Server 2.16.2

Guessing this is related to a change in an upstream dependency (probot-config, probot itself, etc.) that has deprecated one of the modules used for retrieving content within GHE.

I might have expected the stern warning at the bottom of readme might be caveated by enabling of protected branch features.

If it's true that not features of protected branches (ie waiting for +1 or something) can mitigate the "push" = "admin" warning, it would be helpful to acknowledge that in the warning, so readers know that it's not simply an oversight :)

I have this config

Am I missing something or what? :) I also deleted all of the old ones, because I don't care and don't want to rename them.

One more question is popping up... How can we get notified if the config is invalid/broken or whatever? Would be good to open issues when find error.

When .github/config.yml is changed in other branches, it should check the config syntax and report any errors or warnings via the status API.

Sorry, I didn't get a chance to chime in on #90, but it doesn't actually work.

As @jwsloan pointed out in probot/probot-config#10 (comment), we'll need to add special support so that if settings.yml is updated in a .github repository, the changes need to be propagated to all repositories that inherit that config.

cc @pholleran @JasonEtco

This seems like an extension to #1

The proposal would address the concern that enabling this plugin would confuse the process of changing repo settings for people who don't yet know about probot:settings. This is perhaps more important for large organizations who might want to introduce the plugin without "breaking" things for people who aren't yet aware.

Sample painful conversation

bob: I've just set up probot:settings!
alice: ok great, what happens when someone now makes a change from the UI?
bob: good question. I'll assume that we'll have to update the file manually.
alice: ok, how will we know when someone changed via UI? And what will be the consequence if we don't notice?
bob: good point. We'll have to stay vigilant. If we don't, I assume that the next time the file is changed, it will override the change made via UI. But I'm not sure, I'll have to do some testing, and then we can document the edge-cases.
alice: Hm, ok. Given the caveats, is this really worth the process gains?
bob: i'm not sure anymore...

Suggested Feature

To negate these concerns, it would be rad if changes made via the UI were automatically submitted either 1) as updates on default branch, or 2) as a PR to default branch.

(2) seems safer, although might be a little awkward to deal with multiple changes to repo settings, via multiple form saves -- would this involve a specially-named patch branch that is appended to?

Also, there is the outstanding question of whether this requires the addition of a new action to the RepositoryEvent type, so that the plugin can know when something has changed:
https://developer.github.com/v3/activity/events/types/#repositoryevent

It would be helpful to have a CONTRIBUTING.md so I know how to set up the project locally and make changes (and/or test those changes in a live environment).

Protected branches have a lot of different toggles:

• required status checks
• pull request review enforcement
• team restrictions
• user restrictions

I think all of these could be configured via something like this:

protected_branches:
  master:
    required_status_checks:
      include_admins: true  # Enforce required status checks for repository administrators.
      strict: true # Require branches to be up to date before merging.
      contexts: [continuous-integration/jenkins]
    required_pull_request_reviews: true # boolean or 'non-admin'
    teams: [team1, team2]
    users: [person1, person2]

Since the settings.yml might be inherited from a central .github repo, it would be nice to not have to modify the .github/setttings.yml just to update changes. Ideally it could check the commit messages for a special string such as [probot-settings update], and re-apply the config.