Publishing changesets to the code host

Learn how to publish changesets to the code host.

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:

browser_batch_created

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

Requirements

To publish a changeset, you need:

For more information, see Code host interactions in Batch Changes.

Publishing changesets

You can publish changesets either by:

Each of these options has its pros and cons. Here is a summary:

WorkflowProsCons

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

We currently do not support changing the state of a published changeset to draft or unpublished. Once a changeset is published, it can't be unpublished or changed to a draft.

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:

YAML
name: hello-world # ... changesetTemplate: # ... published: true

Then run the src batch preview command again or src batch apply to publish the changesets immediately. 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
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:

publishing_changesets_viewing_progress_and_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:

YAML
# ... 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:

YAML
# ... 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

This feature is supported in Sourcegraph versions 3.30 or more.

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

From the preview

This feature is supported in Sourcegraph versions 3.31 or more.

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

publish_ui_browser_preview

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 apply on:

publish_ui_browser_select_action_on_apply

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, click Apply to publish the changesets. You should see an alert appear indicating that the publication states actions have been updated, and the changesets' "Actions" will reflect the new publication states:

publish_ui_browser_preview_update

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 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.
Previous
Bulk Operations