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!

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?

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?

• 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.

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.