🚀 Publish batch changes from GUI

Created by: sourcegraph-bot

Background

We want Batch Changes to be widely adopted within a company. To achieve that, we need to make sure that the effort required to onboard Batch Changes should be low.

Companies with competing internal tooling typically have increasing internal adoption as a success criteria, and developer experience and UI coverage are a key driver.

Problem

Publishing changesets requires switching context from CLI to the GUI, then back to the CLI. This is creating friction for new users to onboard, and a bad ongoing experience for active users.

Specifically,
When I create a campaign, I start by defining a campaign spec. As it is a new campaign, I set the campaign spec attribute published to false, indicating that all the changesets created by the campaigns will be unpublished.
I run src campaigns preview -f my.campaign.yml.

The command opens a link that takes me to the UI to preview my campaign. I choose to apply it in the GUI (create it on the Sourcegraph instance). The changes look good.
Now I want to publish the changesets (open changesets on the code host).

To do that, I need to go back to the spec (locally), change published to true, then run src campaigns apply -f my.campaign.yml.

create spec (CLI) -> preview (GUI) -> apply (GUI) -> publish (CLI) -> apply (GUI).

Customer feedback

See productboard.

Proposed solution

Success criteria

Success means

• Users can run src batch preview -f, then never leave the GUI

• Users that run Batch Changes in CI or automation can still use the current spec-based workflow (no breaking change)

• The specs is the primary source of truth

Solution

Chris sketched out a solution in his offsite talk, that served as the starting point for this. It allows for 2 workflows, the spec & CLI workflow, and a GUI workflow.

Published is optional in the specs.

If there is no published in the specs, the source of truth is the GUI. A newly created batch change with no published statement in the spec is not published.

• I can go through the GUI to publish/ un-publish them

• and individually pick what changesets to publish/ un-publish

If a user then adds a published statement to the spec and re-applies it, then the status that exists in the GUI (that is, which changesets are published or not) is overridden by what is in the spec. In other words, the spec takes over as the source of truth.

If a user applies a spec with a publish statement, then removes the publish statement and re-applies, the GUI becomes the source of truth.

Since this change introduces two alternative flows to publish changesets, it needs to be clear for users why publishing though the GUI is available or not. For example, when the spec has a published statement, I can see the published button in the GUI, but it's greyed out with a hover "This batch change spec contains a published statement, so publishing is controlled by the spec".

Related issues in scope

• https://github.com/sourcegraph/sourcegraph/issues/17541

Discussion

We can use this as an experiment to driver future decisions on the behaviour of published.

That change eliminates one context switch, but there is still unnecessary context switching. Ideally, an entire campaign lifecycle should be possible from a single interface (GUI / CLI)

Release process

We are not feature flagging this feature since it does not break any existing flow.