Campaigns are part of Sourcegraph code change management and let you make large-scale code changes across many repositories and different code hosts.
You provide the code to make the change, and campaigns provide the plumbing to turn it into a large-scale code change campaign and monitor its progress.
If you are a first-time user of campaigns, we recommend that you read through the following sections of the documentation:
Campaigns allow you to leverage Sourcegraph’s search powers and execute code and Docker containers in all the repositories yielded by a single Sourcegraph search query.
The created set of patches can then be turned into multiple changesets (a generic name for what some code hosts call pull requests and others merge requests) on different code hosts by creating a campaign.
Once the campaign is created, you can track the review state, CI status and open/closed/merged lifecycle of each changeset in the Sourcegraph UI.
You should use campaigns if you want to
See this video for a demonstration of lifecycle of a campaign:
src CLI the user generates a set of patches by running
gofmt over every repository that has a
go.mod file, leveraging Sourcegraphs search capabilities.
This is called executing an action (an action is a series of commands and Docker containers to run in each repository) and yields set of patches, one for each repository, which you can inspect either in the CLI or in the Sourcegraph UI.
The patches are then used to create a draft campaign.
At this point, since it’s a draft camapaign, no changesets (pull requests in the case of GitHub here) have been created on the code host.
The user then selectively creates GitHub pull requests by publishing single patches.
Campaigns currently only support GitHub and Bitbucket Server repositories. If you’re interested in using campaigns on other code hosts, let us know.