-
Notifications
You must be signed in to change notification settings - Fork 1.3k
campaigns: allow partial publishing of changesets #13476
Conversation
9963f38
to
2769aa5
Compare
2769aa5
to
21632e0
Compare
go.mod
Outdated
@@ -5,6 +5,7 @@ go 1.14 | |||
require ( | |||
cloud.google.com/go/bigquery v1.6.0 // indirect | |||
cloud.google.com/go/pubsub v1.3.1 | |||
github.com/LawnGnome/campaign-schema v0.0.0-20200928040853-342b51d40db7 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we create github.com/sourcegraph/campaigns-schema
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I totally forgot to write this down last night, because I was rushing: assuming we go with this approach, I intend to move this to github.com/sourcegraph/campaignutils
, by analogy with codeintelutils.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me.
internal/campaigns/types.go
Outdated
@@ -1714,7 +1716,7 @@ func (cs *CampaignSpec) Clone() *CampaignSpec { | |||
// UnmarshalValidate unmarshals the RawSpec into Spec and validates it against | |||
// the CampaignSpec schema and does additional semantic validation. | |||
func (cs *CampaignSpec) UnmarshalValidate() error { | |||
return unmarshalValidate(schema.CampaignSpecSchemaJSON, []byte(cs.RawSpec), &cs.Spec) | |||
return unmarshalValidate(cschema.CampaignSpecJSON, []byte(cs.RawSpec), &cs.Spec) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mental note: we could move unmarshalValidate
, with its yaml/json stuff, into cschema
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. I'll create a follow up issue.
BTW, it would be nice if you could describe what this is in the PR title instead of just "RFC 228", for all the people who aren't familiar with that RFC. 😃 |
Definitely, now it feels like this moving past being a PoC of an RFC option! I'll update this and the src-cli PR in a moment, since I'm doing some RFC gardening right now. |
e98fd2d
to
f52f466
Compare
Flipped to review-ready. As with src-cli, 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 |
Notifying subscribers in CODENOTIFY files for diff af8941b...e86a527.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sweet!
Please add docs! :)
At the very least the part about published
in the YAML reference should be updated with examples etc. And in the best case, the new capability is also shown in the "Publishing changesets to the code host" section
@@ -28,7 +29,7 @@ func testStoreCampaignSpecs(t *testing.T, ctx context.Context, s *Store, _ repos | |||
Commit: campaigns.CommitTemplate{ | |||
Message: "commit message", | |||
}, | |||
Published: false, | |||
Published: override.FromBool(false), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just an idea I had when looking at this and thinking about the naming of the package and the function: how about something like overridable.NewBool(false)
? Not saying it needs to be done in this PR or now, but override.FromBool
makes me think "override from a bool? what's being overridden?"
And var published overridable.Bool
also reads well :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overridable
is definitely better. I'll make that change.
The reason I didn't use New
is because it's not a heap allocation. (Directly, anyway. What Go chooses to do behind the scenes is its business.) I don't have super strong feelings on this, but I was looking for a verb that described what was generally happening, and From
felt as good as any (converting a bool
to an overridable.Bool
).
Does changing the package name (ie overridable.FromBool()
) address that concern?
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
I was going to do that in a separate PR, but actually, you're right. I'll update this PR. |
Docs added. PTAL! |
CHANGELOG.md
Outdated
@@ -16,6 +16,7 @@ All notable changes to Sourcegraph are documented in this file. | |||
- The new GraphQL API query field `namespaceByName(name: String!)` makes it easier to look up the user or organization with the given name. Previously callers needed to try looking up the user and organization separately. | |||
- Changesets created by campaigns will now include a link back to the campaign in their body text. [#14033](https://github.com/sourcegraph/sourcegraph/issues/14033) | |||
- Users can now preview commits that are going to be created in their repositories in the campaign preview UI. [#14181](https://github.com/sourcegraph/sourcegraph/pull/14181) | |||
- The `published` flag in campaign specs [may now be an array](https://docs.sourcegraph.com/@main/user/campaigns/campaign_spec_yaml_reference#publishing-only-specific-changesets), which allows only specific changesets within a campaign to be published based on the repository name. [#13476](https://github.com/sourcegraph/sourcegraph/pull/13476) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Recommend starting with the more important bit:
You can now publish a subset of changesets in a campaign ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, although I went with slightly different wording to better fit the house style of the changelog (which doesn't usually address entries to a reader):
- A subset of changesets can now be published by setting the
published
flag in campaign specs to an array, which allows only specific changesets within a campaign to be published based on the repository name. #13476
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor doc changes, otherwise lgtm. Thanks for writing docs!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice docs! Thank you!
(btw. you should go nuts with this in #progress and also record video/gif/whathaveyou)
@@ -130,9 +130,11 @@ name: hello-world | |||
|
|||
changesetTemplate: | |||
# ... | |||
published: false | |||
published: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What. the. hell. How did I manage to get that wrong? 😄
If no entries match, then the repository will not be published. To make the default true, add a wildcard entry as the last item in the array: | ||
|
||
```yaml | ||
published: | ||
- github.com/*: false | ||
- "*": true | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't this just mean "published: true"? Wouldn't the wildcard "*" need to be the first entry to set the default to true?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes just enough changes to support the prototype in sourcegraph/src-cli#294. See that PR for more detail on what's going on.