Create batch changes on forks

Created by: sourcegraph-bot

User problem

For enterprise customers

• Most users do not have write permission on all repositories, so branch creation fails for them (https://github.com/sourcegraph/accounts/issues/544)
• Some companies enforce that all PRs created by automation are opened on forks. (https://github.com/sourcegraph/accounts/issues/565, https://github.com/sourcegraph/accounts/issues/4778 )

For OSS users in the future, forks is the only possible workflow

Why now

• blocking rollout at https://github.com/sourcegraph/accounts/issues/4778
• must have and blocking large scale rollout at https://github.com/sourcegraph/accounts/issues/565

Proposal

MVP

Story:

• As a site admin, I can set up Batch Changes to only use forks.
• If that is set up, as a user all my batch changes will be created on forks.

There is a global config parameter batch_changes.enforce_forks, defaulting to false. If set up to true, all changesets will be created from a branch on a fork. The fork will live in the namespace tied to the access token used by batch change to create the changesets:

• If a service account is used, the service account's namespace will be used. For each repository in the batch change, a fork will be created if it doesn't exist.
• If a personal access token is used, the user's namespace will be used.

UI changes

In the MVP, the main UI change is that we need to indicate to the user if a changeset lives in a fork or not. We can do so with a visual cue (a fork symbol, although I re-used a not-quite-a-fork0symboil placeholder for illustration). We keep using site-admin-defined, per codehost path pattern.

Schema: Example:

It's possible that the fork does not exist (it's never been created and the batch change is still in preview or unpublished). In that case, it's reasonable for the link to the fork to 404.

Limitations and alternatives considered

Limitations

A downside of allowing forks is that the creator of the campaigns ends up with a lot of forks (100 campaigns means 100 forks). Using a service account with batch changes mitigates this problem (only the service account ends up with many forks). Overall, we think that either customers will be fine with having lots of forks, or will use a service account.

Alternatives

We worked around the need for forks by building service accounts, but that was insufficient because:

• customers that need permission enforcements cannot use service accounts
• site admin may choose to not give write access on some sensitive repos to the service account
• new repos are often left out of the service account forks
• most of all, some companies just enforce that automation uses forks

Future work

• Fork-settings are linked to credentials. Each PAT or service account token has a setting to use forks or not. Site-admins can override this, and enforce that all changesets created by Sourcegraph are on forks.
• Should there be a "default to fork if permission error". As a user, provided there is no site-admin level fork-setting, I can set up Batch Changes to create a fork instead of a branch if creating a changeset errors due to permission issues. Blocked by: #24307

Next steps

• validate current MVP scope with customers
• design: how do we represent forks vs branches in the GUI