a8n: Implement CampaignPlan & ChangesetPlan in GraphQL API

Created by: mrnugget

This is part of #6085 (and RFC 42) and implements the GraphQL resolvers for the CampaignPlan and ChangesetPlan entities that were stubbed out until now.

There's nothing really tricky here: it pulls CampaignPlans and CampaignJobs out of the database and wraps them in resolvers so that the all the fields of in the schema work.

It's a massive amount of boilerplate.

Noteworthy is that I could reduce the number of Go interfaces needed by having the ChangesetPlansConnectionResolver, which is *campaignJobsConnectionResolver here, implement two GraphQL fields on CampaignPlan: RepositoryDiffs and Changesets. That gets rid of having to have an intermediate PreviewRepositoryDiffsConnectionResolver and doing that whole dance twice.

TODOs:

• Change the placerholder title and description (@sqs what should those be? Since the plan is not connected to a Campaign yet and the possibly hasn't entered title/description yet, we can't use that)
• Respect connection args in campaignPlanResolver.Changesets & campaignPlanResolver.RepositoryDiffs

Created by: sqs

Re: the planned change sets’ title and description, from the user’s POV they should be the campaign title and description (for now; much later on we’ll make these customizable per-changeset). I understand that the API doesn’t accept those parameters as inputs because a plan is “lower level” than the campaign itself. I would propose somehow moving those parameters into the campaign plan specification OR having the UI inject those values (because it knows the campaign title and description) and having the plan API return empty strings for the title and descriptions.

This is definitely a weirdness/oversight I didn’t catch in the API design, but I think either of those workarounds would be fine. I am ambivalent from a product POV but as an engineer I slightly lean toward the latter since it doesn’t introduce ugliness into the API right now. Your call, though.

Created by: mrnugget

I would propose somehow moving those parameters into the campaign plan specification OR having the UI inject those values (because it knows the campaign title and description) and having the plan API return empty strings for the title and descriptions

I think the second option — the UI filling in the title/description dynamically — is the better one, since it works for the cases when (a) user hasn't typed in a title/desc yet (b) user is typing it in (c) user typed it in.

And, besides that, I don't think it makes sense to accept title/desc for previewcampaignPlan since the CampaignPlan doesn't have anything to do with title/desc yet.

This is definitely a weirdness/oversight I didn’t catch in the API design

This is exactly the type of thing that I expected we will run into and discuss when we come across it, so, everything's going according to plan :)

I am ambivalent from a product POV but as an engineer I slightly lean toward the latter since it doesn’t introduce ugliness into the API right now. Your call, though.

@felixfbecker @eseliger What do you think? If we say we return empty strings for ChangesetPlan.{title,description}, we can remove the fields altogether, right?

Created by: codecov[bot]

Codecov Report

Merging #6430 into master will increase coverage by 0.08%. The diff coverage is 62.89%.

@@            Coverage Diff            @@
##           master   #6430      +/-   ##
=========================================
+ Coverage   39.21%   39.3%   +0.08%     
=========================================
  Files        1192    1192              
  Lines       61061   61196     +135     
  Branches     5825    5825              
=========================================
+ Hits        23946   24053     +107     
- Misses      34922   34934      +12     
- Partials     2193    2209      +16

Impacted Files	Coverage Δ
cmd/frontend/graphqlbackend/a8n.go	0% <ø> (ø)
enterprise/pkg/a8n/resolvers/changesets.go	73.27% <100%> (+0.46%)
enterprise/pkg/a8n/resolvers/campaign_plans.go	63.58% <59.58%> (+63.58%)
cmd/frontend/graphqlbackend/repository.go	21.84% <0%> (-0.98%)
enterprise/pkg/a8n/resolvers/resolver.go	34.45% <0%> (+1.49%)

Created by: felixfbecker

SGTM, I agree with we return empty strings anyway I'd rather completely remove them