We are having issues with a GitHub App not being able to start builds in CircleCI. We have several repositories hooked up to build on CircleCI using restricted contexts for security purposes. We have a GitHub App, dependabot, installed to our GitHub organization for all of these repositories. The app creates a new branch with a pull request when it detects newer versions of dependencies for our repositories.
However, when this new branch is created, it triggers a build in Circle on that branch. This is so we can verify that a dependency update passes all CI checks (ex. tests, linting, compiling) before we merge the PR. Because the app user is not a member of any of the GitHub teams associated with the job context, the CircleCI build fails with an “Unauthorized” error.
We realize that we need this user to be associated with a team in GitHub, but as far as we can find there is no way to add that app user to our teams. How would we go about giving a GitHub App user access to a context without giving all users access to the context? We use contexts for security purposes such as separating regular developers from those with production access (hence preventing them from seeing any production-related secrets or kicking off prod deployments in Circle); we really do not want to give up these access controls just so this app can trigger builds in Circle for those PRs.
Hello @CalMlynarczyk! Due to the nature of the bot, it’s unfortunately not possible to use contexts with the user. Typically users will either remove the contexts from the jobs that the bot triggers, as depending on the workflow they don’t require sensitive environment variables, or they will create a separate workflow could be created that runs similar steps but does not need to utilise the contexts.
@gmemstr Thanks, found out someone on our team reached out to Circle’s support email a couple of weeks back and got a similar response. It expands on what you said and might be helpful to other people for future reference:
Due to the nature of dependabot it is not possible to use restricted contexts. This also ties into the intended use case of contexts - typically they contain sensitive information, which should be out of reach of users that are not in the GitHub organization or team. Trusting a bot that is not directly controlled by the organization with secrets could be seen as a security hole. The best way around this would be to manage module updates manually, but this may prove infeasible depending on the project constraints. Jobs that are required to be run for dependabot could have their contexts moved to environment variables instead, as this would allow any user, especially dependabot, to run the jobs as intended. Workflow filters and regex could be used to filter the dependabot branches into their own workflow and jobs without the contexts.