Plugin is not working at all

[mmornati]

Following the documentation it should be "zero" configuration plugin. After the add to our organization (with a first test on only some repositories) the plugin is present but it taking no action at all.

The actual configuration we have:

But when we want to activate the check on the branch it is not visible:

We even try to activate the plugin forcing the configuration into the .github folder

Is there anything we are missing?

[zeke]

That's strange. Sorry it's not working for you.

You are right to assume that no configuration is necessary after you've installed the GitHub App on your organization or select repos. The service is definitely running and responding with status checks for projects like electron/electron. See https://github.com/electron/electron/pull/16082 for example.

Maybe it's something about your org... can you try installing on a repo outside that org and see if you have better luck?

[mmornati]

It is even installed on my opensource repos but, the same, I'm not able to see the plugin in the list of status check. Is there anything I need to do before to activate it? It should be available on any repository here: https://github.com/mmornati

GitHub

mmornati - Overview

mmornati has 63 repositories available. Follow their code on GitHub.

[mmornati]

After some checks in the end on the OpenSource repositories is working

Do you know how we can enable it on the organization? The WIP plugin (just to give you an example) is working good.

[chmaltsp]

On our private repo, it also stopped working the other day although was there for a while before. No semantic.yml either

[zeke]

@chmaltsp did it start working again, or stopped completely?

[chmaltsp]

Stopped completely On Mon, Dec 17, 2018 at 6:09 PM Zeke Sikelianos notifications@github.com wrote:

@chmaltsp https://github.com/chmaltsp did it start working again, or stopped completely?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/probot/semantic-pull-requests/issues/38#issuecomment-448033578, or mute the thread https://github.com/notifications/unsubscribe-auth/AKeSTdb8UoPNEZeABCoDQwsjrOHedQPYks5u6CQQgaJpZM4ZTSuA .

[zeke]

Sorry this is happening folks. I don't see why it would be working for some repos and orgs, but not for others. I will need to consult the server logs to help diagnose the problem.

[paszkowskiDamian]

I have the same issue in my private repos. I'll try adding semantic.yml to see if it will fix it. I tried to remove bot and then add it again but then I'm not getting any statuses.

[zeke]

@paszkowskiDamian are your private repos in a private org? In https://github.com/probot/semantic-pull-requests/issues/23#issuecomment-421454217 I was able to use this bot on a private repo without issues.

[paszkowskiDamian]

Yes, it is a private repo of organization, but it used to work well up until last week.

[mmornati]

Any news about the private repo problems? Is still failing on all our repositories but it is ok on OpenSource ones. What I can share more, if it can help, the oeginizarion is secured with a private SSO system. But about the applications, I think this should not have impact (as WIP plugin works).

[zeke]

Lying in bed this evening putting my kids to sleep, pondering the great mysteries of the universe, it came to me! I think the bot stopped working for private repositories when https://github.com/probot/semantic-pull-requests/pull/30 landed, which introduced support for configuration of the bot using a .github/semantic.yml file. The GitHub App's token doesn't include a scope for reading repository contents. For public repos this change had no negative effects because unauthenticated API requests for files still work, but for private repos those requests are likely now failing and causing the bot to fall over.

@paszkowskiDamian based on your comment above, the timing sounds about right, as #30 landed on November 28.

One way to work around this would be to preserve the current minimally-invasive token scope by disallowing semantic.yml configuration for private repos, but that seems weird to have a different behavior between public and private repos. 🤔

I think the best option now is to update the GitHub app to require read access to repository contents. Are folks willing to give this bot read access to their private repo contents, though?

[mmornati]

Hey. Great to know 😊

About the "how" it is a good question: on our side we are accepting "github" plugins (developed by github directly) but we are taking care to all others...especially if they are requiring file access. The reason is simply related to security: we don't know what plugin maintainers do with the retrieved data (are they logging somewhere plugin runtime information?).

Anyway, take the decision you want for your plugin...we will then check on our side if the security département allow the activation :)

Thanks

[paszkowskiDamian]

Thanks!

Maybe having a public repo .github in an organization would solve this. I'm not sure how sensitive configs might be.

Additionally, if there is no config file, but there is a repo in the org named .github, it will be used as a base repository.

octocat/repo1:.github/test.yaml <-- missing! octocat/.github:.github/test.yaml other: III https://github.com/probot/probot-config

or you can change bot access rights to the single file.

[zeke]

Thanks @paszkowskiDamian! I wasn't sure if single-file access was generally available yet. I've added that to the permissions, with the following message for users:

Recent updates from the community make it possible to (optionally) customize behavior using a .github/semantic.yml configuration file. These new permissions make that file readable on private repositories.

Please accept these updated permissions and let me know if the bot is working for you now.

[paszkowskiDamian]

Thanks, @zeke! It started to work again 🎉

// https://github.com/probot/probot-config/blob/master/lib/index.js
async function loadYaml(context, params) {
  try {
    const response = await context.github.repos.getContents(params);
    return parseConfig(response.data.content);
  } catch (e) {
    if (e.code === 404) {
      return null;
    }

    throw e;
  }
}

loadYaml is a part of getConfig, and it only handles cases where config is not found.

[mmornati]

Yeah finally we can use the plugin even in our private repositories. Thanks for the fix:

[zeke]

Thanks for reporting back, folks! I'm going to close this out.

[ajaij]

@zeke This issue is happening for me as well, am using a private repo inside a private org, after installing the app when navigated into branch settings, am not able to see the option under "status checks" checkbox.