https://build.snapcraft.io is our pitch to the GitHub generation. It guides you through getting snaps automatically built and published to edge from your GitHub repositories. It’s ready for use with personal repos and launching as a beta shortly.
For the GA in late May we need to support organisation repos, which account for 85% all pull requests on GitHub.
In order to ensure that:
Snaps created for organisation repos show as published under the organisation name in snap list
Admins of the GitHub organisation can promote a snap revision from edge
The following must be set up:
An SSO account for the organisation
SSO accounts for each of the GitHub organisation admins
However:
This is time-consuming and duplicative. They’ve already mapped out their permissions in GitHub.
If someone leaves the organisation, other admins have to remember to remove them from the snap collaborators list for every organisation-owned snap.
I’d like to suggest we employ GitHub’s webhooks to transparently maintain which SSO accounts should be collaborators on snaps owned by SSO “GitHub organisation identity” accounts.
The first organisation admin to log into https://build.snapcraft.io would be guided to create the SSO account for the organisation, as well as their own. Any snaps created for organisation repos would be:
Automatically registered to the organisation SSO account
Automatically shared with the SSO accounts of admins of that organisation
Automatically unshared when admins leave the organisation
There are a couple of concerns with automatically syncing GH admins to snap collaborators:
We are fully delegating authority for who can publish revs of these snaps to a 3rd party
GH admins can add other admins, meaning a collaborator can add other collaborators. In the snappy design and Store implementation, only a publisher is allowed to control collaborators.
We have to special case these snaps to forbid collaborator changes from snapcraft to avoid collisions/races w/the sync job
I’m afraid that this proposal does not accurately match the GitHub permissions model. It’s possible for users who are not members of an organisation to be added as collaborators on a GitHub org repository, even as admins. For example, a couple of members of Canonical’s web team are admins on canonical-ols/build.snapcraft.io, despite not being members of the canonical-ols organisation.
Organisation SSO accounts still make sense for this, and I agree that we need to be handling it automatically as far as possible, but we need to handle permissions on a per-repository/snap basis, not per-organisation.
We are delegating the membership check for the admin group of an organisation. The authority is still expressed in SSO accounts.
Only one person can ever add collaborators? Can you point me at where that was decided? It seems problematic, least of which because that person might go on holiday and leave the rest of their team up a creek.
Correct. No one has expressed a use case for having additional collaborators to those defined via the GitHub organisation admin group.
I think if we want a list of individuals who are responsible for the brand, it’s the admins of the GitHub organisation. It’s Amazon Web Services in the case of https://github.com/aws/amazon-ecs-agent –not the ECS developers–appearing in the vendor field.
However, I think the group most likely to make the call on promoting from edge are the admins of the repo, as you allude to with the canonical-ols/build.snapcraft.io case.
The design has always been (someone correct me if I’m mistaken here) that a snap has a single publisher, and the publisher sets all the rules/policies for the snap. I would consider the list of collaborators to be policy.
This is correct. It can be verified in the snappy system design doc, there is clearly stated that the only one defining the list of collaborators is the publisher of the snap.
This is also reinforced by the design of the snap-developer assertion where it has to be signed by the publisher.
The extension to allow Canonical to sign such assertion was only added to allow for snap ownership transfers, not to override the publisher intention about the list of collaborators.
The idea of synchronizing administrators feels a bit like mixing accounts and roles in two independent systems, which invariably creates more pain than it relieves.
Instead, I suggest we take the view of respecting the role of each of the systems, and keep accounts in GitHub and the Store as independent entities, and then create the concept that some of the organization accounts in the Store may be linked to the GitHub organization.
When that takes place, GitHub users which are administrators in the linked GitHub organization may request access to that Store organization account and act as an administrator there as well. Comparing to the suggested “sync all” approach, this is more of an on demand approach, where we allow administrators to request access if and when they need. The link also implies users which are no longer in the GitHub account should lose access to their access to the Store organization account.
Then, those administrators can assign specific people to be responsible for releasing revisions from edge into other channels. Those people need to have their own Store accounts as sensible for any such organization account, and very often they will not be administrators in GitHub.
As a side note, we should avoid the terminology of “SSO account” when talking about organizations. These accounts shouldn’t be able to login at all by themselves, and instead be driven by their administrators which should have their own accounts.
Then, those administrators can assign specific people to be responsible for releasing revisions from edge into other channels.
These people are GitHub users, correct? You can immediately select from a list of GitHub users who should be able to release revisions to channels, but that these individuals must create SSO accounts before they can use the power.
That sounds like a general feature we want in the store no matter whether the account is linked with GitHub or not. When the cross-system organization link is in place, what we can do to give a hand is prevent the permission from being granted to store users which are not also present in the GitHub organizations, but it sounds to me like the user experience in the store should be tuned to support local interactions instead of GitHub ones, otherwise we’ll need to redo it all for accounts which are not linked with GitHub.
The worry I have is that the setup gets slowed down by serialisation: you have to chase your release managers to create accounts before you can add them in.
Trello handles this by letting you add people to an organisation by their email address, before they’ve created an account. Doing so sends them an invite mail, which automatically places them in the organisation.
I think we could reasonably do much the same here. Select a few GitHub users in the build.snapcraft.io UI and if they don’t have a matching local account, an invite is sent to create one.
For what its worth… This is a pattern i’ve seen used several times. Doesn’t travis even do something like this?
I think when I used drone.io (open source version of it) with github authentication it would give read access if they had access to view the repo to view builds. But it wouldn’t let them manage with out explicitly being promoted by the person that initially set that repo up in drone.
@evan Sorry for the lack of update here. We had a call last week and discussed this, and the requirement established was to scale down the feature significantly so it can be done sooner and then polish over time. To that end, we’d probably end up with just a dummy automatic account created and managed by the one person that sets the GitHub conversation with the build machinery, and that’s about it.
@niemeyer that’s okay. I caught up with Bret and Mark after that call. Sorry for not having been there; I had another meeting that ran way over.
We’re full speed ahead on listing GitHub organisation repos that you’re an admin of (because webhooks) and letting you add those. For those of you eager to see this, we’re confident it will land in May.
