Run job with restricted context?

Build Environment
1

So, I recently started testing the test publish feature of orb-tools

However, due to orbs needing to be published by an owner, I use a restricted context for the token. This means that a commit / PR generated by a bot, or a user who’s not part of the team that owns that context, will have that dev publishing step fail.

Is there a way (without using API triggers) to use an “approval” workflow to run a workflow step that allows a reviewer who is in the restricted context to approve the dev publishing job? Any other workarounds to support this (IIRC, Circle may do something like this for its own orbs?)

2

Hey @wyardley,

We recommend adding the bot to a group that can be added to access the restricted context. Funny enough to your suggestion, this is actually exactly what we did a while back, however the approval job context switching was removed as it believe there were potential security concerns for unintended or automated approvals. We also personally found that users rarely went into CircleCI and remembered to approve the job, so it worked out that the feature might as well have been removed because we got to lower the friction for testing orb updates just a little.

Now, you will have building forked PRs and Shared secrets off for obvious security reasons, which means if a user forks the project and submits a PR, the tests will not run automatically, and the PR will report that it is in awaiting status if you have CircleCI Status Checks enabled. To test the PR, pull the PR in locally and push up the branch to your repo. The easiest way to do this is with the github cli:

gh pr checkout 01
git push -u origin

Now ^ This commit will be authored by you, but reference the same SHA1, so the job will run on CircleCI, and the original PR will update with the status checks.

3

Thanks. However, how can I do that - as best I know, app users (vs machine users) cannot be added to groups. For example, when using the app version of “Renovate”, it creates an app user vs. a “real” GitHub user.

4

In this case we would indeed need a “machine” user.

This is currently how we here at CircleCI are publishing our orbs. We have a group in our org for the orb publishing team and manage the automated creds via an orb publishing user in that GitHub team. That GitHub team is where we are restricting our context to.

Now, when any of the users in this group pull in and push up the user PRs, they will have the proper access to allow the pipeline to run.

–

tldr version:

  • Create a “machine” user on GitHub.
  • Create a team on GitHub called orb authors (or similar).
  • To have full production publishing rights, the machine user must also be made an owner of the organization. We will not be using any permissions tied to GitHub with this user, the “owner” status is not needed for permissions, it is used to limit who can publish as we can not use “teams” here like we do with contexts.
  • Create a CircleCI Personal Access Token for the machine user while logged in as them. This token can be used to publish full versions of orbs.
  • Add the machine user + any maintainers to the team.
  • Restrict the context containing your publishing token to the team you just created.

Now any member of the team can pull down and push up a forked PR and have it run completely.

5

@KyleTryon Renovate (the app creating the commits) can’t run as a machine user, though; that’s the issue.

The user with permissions to publish the orb already is a real user, and that part of it works fine.

(and yes, also familiar with the org owner requirement for publishing orbs - this would be a really nice thing to have a fix for, since I don’t want to make any of our machine users org owners). For example, an allowlist of users or groups that can publish orbs vs. having it only work for org owners.