publishing_changesets.md

Publishing changesets to the code host

<style> .publishing-changesets td { vertical-align: top; } /* ul elements are picking up the default browser style of 1rem top and bottom, so we should align the other cells the same way. */ .publishing-changesets td > *:first-child { margin-top: 1rem; margin-bottom: 1rem; } </style>

After you've created a batch change with the published field set to false or omitted in its batch spec, you can see a preview of the changesets (e.g., GitHub pull requests) that will be created on the code host once they're published:

In order to create these changesets on the code hosts, you need to publish them.

Requirements

To publish a changeset, you need:

1. admin permissions for the batch change,
2. write access to the changeset's repository (on the code host), and
3. a personal access token or a global service account token configured for the code host.

For more information, see "Code host interactions in Batch Changes". Forking the repository is not yet supported.

Publishing changesets

You can publish changesets either by setting the published field in the batch spec, or through the Sourcegraph UI. Both workflows are described in full below.

A brief summary of the pros and cons of each workflow is:

Workflow	Pros	Cons
Setting published in the batch spec	If you reuse your batch spec, or share it with others, the new batch changes will have the same changesets published Easy to publish changesets in large batch changes based on specific criteria, such as the organization each repository is in	Requires the batch spec to be re-applied before changes take effect, which can be slower Requires more context switching from the UI back to the spec file when previewing diffs
Publishing from the UI	Rapid feedback loop: you can check a specific diff and immediately publish it Easy to publish random changesets without having to specify rules in the published field	Publication state isn't reproducible across multiple batch changes

Within the spec

When you're ready, you can publish all of a batch change's changesets by changing the published: false in your batch spec to true:

name: hello-world

# ...

changesetTemplate:
  # ...
  published: true

Then run the src batch preview command again, or src batch apply to immediately publish the changesets.

Publishing a changeset will:

• Create a commit with the changes from the patches for that repository.
• Push a branch using the branch name you defined in the batch spec with changesetTemplate.branch. If forks are enabled, then the branch will be pushed to a fork of the repository.
• Create a changeset (e.g., GitHub pull request) on the code host for review and merging.

NOTE: When pushing the branch Sourcegraph will use a force push. Make sure that the branch names are unused, otherwise previous commits will be overwritten.

In the Sourcegraph web UI you'll see a progress indicator for the changesets that are being published and any possible errors:

If you run into any errors, you can retry publishing after you've resolved the problem by running src batch apply again.

You don't need to worry about multiple branches or pull requests being created when you retry, because the same branch name will be used and the commit will be overwritten.

Publishing a subset of changesets

Instead of publishing all changesets at the same time, you can also publish some of a batch change's changesets, by specifying which changesets you want to publish in the published field:

# ...

changesetTemplate:
  # ...
  published:
    - github.com/sourcegraph/src-cli: true
    - github.com/sourcegraph/*: true
    - github.com/sourcegraph-private/*: false

See changesetTemplate.published in the batch spec reference for more details.

Publishing changesets as drafts

Some code hosts (GitHub, GitLab) allow publishing changesets as drafts. To publish a changeset as a draft, use the 'draft' value in the published field:

# ...

changesetTemplate:
  # ...
  published: draft

See changesetTemplate.published in the batch spec reference for more details.

Fully publishing draft changesets

If you have previously published changesets as drafts on code hosts by setting published to draft, you then fully publish them and take them out of draft mode by updating the published to true.

See changesetTemplate.published in the batch spec reference for more details.

Within the UI

NOTE: This functionality requires Sourcegraph 3.30 or later, and also requires src 3.29.2 or later.

To publish from the Sourcegraph UI, you'll need to remove (or omit) the published field from your batch spec. When you first apply a batch change without an explicit published field, all changesets are left unpublished.

From the preview

NOTE: This feature requires Sourcegraph 3.31 or later.

When you run src batch preview against your batch spec and open the preview link, you'll see the current states of each of your changesets, as well as a preview of the actions that will be performed when you apply:

For any changesets that are currently unpublished or only published as drafts, you can select the checkbox and choose an action from the dropdown menu to indicate what publication state you want to set the changesets to on apply:

NOTE: Certain types of changeset cannot be published from the UI and will have their checkbox disabled. Not sure why your changeset is disabled? Check the FAQ.

Once the preview actions look good, you can click Apply to publish the changesets. You should see an alert appear indicating that the publication states actions have updated, and the changesets' "Actions" will reflect the new publication states:

From an open batch change

Once applied, you can select the changesets you want to publish from the batch change page and publish them using the publish bulk operation, as demonstrated in this video:

Specifying Git commit details

Regardless of how you publish your changesets, the commit that's created and pushed to the branch uses the details specified in the batch spec's changesetTemplate field.

See changesetTemplate.commit for details on how to set the author and the commit message.