As the Organization owner of github.com/hyper-expanse, and the registrant of the hutson namespace in the Circle CI Orb registry, I have the ability to publish production Orbs under that namespace.
I do not manually publish Orbs, but instead, automate the process. That is because:
Publishing is a tedious process that does not add value to the process.
Changes to an Orb are vetted as part of the Pull Request review process. Once a change has been approved by the owner of an Orb, and subsequently merged into the repository’s default branch, the assumption by all those involved is that the change may be published to production.
Because only namespace owners may publish Orbs into production, my current workflow involves exposing a Circle CI Orb token through a Context to a CI job that does the publishing.
I would prefer not to use my personal token. Doing so has several drawbacks:
All publishes occur as me, even if I am not the individual contributing a change, or approving it.
If I were to leave the GitHub organization, the workflow would break until another GitHub organization owner updates the Context with a new personal token.
Your use case is perfectly valid, and a common concern in modern architecture where “promotions” or “deployments” have become non-human concerns. Unfortunately as you have discovered our services are tied to specific user accounts, and that includes the interactions with Orb publishing.
While we continue to collect feedback and evolve our orb offering, including RBAC, I can only offer a work-around. To help users solve similar deployment problems elsewhere, Github suggests the creation of a “Machine User” that has the rights required. This should address your two primary concerns by moving the ownership to a single protected non-human account with org level permissions.
I’ll also make sure we have an idea card tracking this need specifically if not in our story collection yet.
Our organization created a bot account several months ago to facilitate the creation of GitHub Releases (You can see how we use Circle CI to manage that job in my semantic-delivery Orb example).
Agreed!
It seems like a like-for-like trade-off in that, though we end up with a machine user that has owner access to our organization, the account, technically, has no more permissions than my own.
It would be really nice, though, if some day we can migrate away from machine users with owner permissions, as they still introduce a significant single point of risk.