campaigns: allow partial publishing of changesets

[LawnGnome]

This is a prototype of the option being presented in RFC 228. It needs to be used in conjunction with sourcegraph/sourcegraph#13476.

Note that this PR adds a dependency on https://github.com/LawnGnome/campaign-schema for schema-related code shared between this PR and sourcegraph/sourcegraph#13476; my intention is to move this to https://github.com/sourcegraph/campaignutils if accepted.

An example of the type of campaign you could run with this is:

name: hello-world
description: Add Hello World to READMEs
​
# Find all repositories that contain a README.md file.
on:
  - repositoriesMatchingQuery: file:README.md r:github.com/*
  - repositoriesMatchingQuery: file:README.md r:gitlab.sgdev.org
​
# In each repository, run this command. Each repository's resulting diff is captured.
steps:
  - run: echo Hello World | tee -a $(find -name README.md)
    container: alpine:3
​
# Describe the changeset (e.g., GitHub pull request) you want for each repository.
changesetTemplate:
  title:
    default: Hello World
    except:
      - github.com/sourcegraph/*: Hello Sourcegraph!
  body: My first campaign!
  branch: hello-world # Push the commit to this branch.
  commit:
    message: Append Hello World to all README.md files
  published:
    - github.com/LawnGnome/*: true

[mrnugget]

NICE! I like this the most so far.

Two thoughts:

1. The only: in the title: acts more like an overwrites: oder except: instead of an only:: "default value is 'Hello World', except when we match this, then it's "Hello Sourcegraph".
2. The match in published.except: is not prefixed with match:. I wonder whether we could make that more uniform.

I feel like we're now 95% there!

[LawnGnome]

This is roughly updated in line with the RFC and its discussion.

One thing we should talk about further is that I've separated out the schema and OverridableString into a new repo, which I've temporarily namespaced under my own user until we decide what we want to do. The reason for this is because we'll need a lot of this in sourcegraph/sourcegraph as well, so it makes sense to me to migrate the schema and common types into that repo. I'd still need to move OverridableBool into that repo, but it's late, and I think this is enough to get a general sense of where this would be going.

So, concerns?

[mrnugget]

Few thoughts on the schema and OverridableString:

1. Do we really need the whole functionality in sourcegraph/sourcegraph? I know that we need to share the raw JSON schema so we can do validation in the API layer, but while we currently do unmarshal the CampaignSpec into a Go struct, we don't really need to, right? We're currently only using the top-level fields, such as name, description. Considering this, I think only in src-cli would we need to expand and evaluate the globs in the campaign spec. (Of course, with server-side execution we would need all of that in sourcegraph/sourcegraph, so maybe you meant that)
2. code intel related code in src-cli imports github.com/sourcegraph/codeintelutils — that would be our equivalent here, right?

[LawnGnome]

• Do we really need the whole functionality in sourcegraph/sourcegraph? I know that we need to share the raw JSON schema so we can do validation in the API layer, but while we currently do unmarshal the CampaignSpec into a Go struct, we don't really need to, right? We're currently only using the top-level fields, such as name, description. Considering this, I think only in src-cli would we need to expand and evaluate the globs in the campaign spec. (Of course, with server-side execution we would need all of that in sourcegraph/sourcegraph, so maybe you meant that)

We don't, but we will, as you said. I'm happy enough to cut this back and embed the logic in src-cli for now, but with server side execution the shared bits will need to be shared.

• code intel related code in src-cli imports github.com/sourcegraph/codeintelutils — that would be our equivalent here, right?

Exactly.

[eseliger]

Very cool, so simple and straightforward!

[LawnGnome]

Flipped to review-ready. I'm going to dismiss the existing approvals, but I don't think there's anything controversial here.

The original branch that supported strings is pushed to the aharvey/override-strings branch.