Something went wrong while fetching comments. Please try again.
Created by: mrnugget
IMPORTANT! Note for reviewers: There still a lot of TODOs, but I don't want to tackle all of them in this PR, otherwise the PR grows too large and our changes to the API diverge. And I want to now get a review as early as possible. See the two checklists below for what I want to do in this PR and what not before you review.
@efritz can you take a look at workers.go
to see whether I'm doing anything wrong?
This PR implements the majority of the new workflow's backend logic:
reconciler.go
) is a workerutils.Worker
that runs in the background and picks up enqueued changesets to reconcile their current state (in the Sourcegraph DB or on the code host) with the desired state the user expressed in a changeset spec.applyCampaign
mutation now correctly creates changesets for a given campaign so that the user can apply a campaign spec and immediately see unpublished/published changesets in the UI that the reconciler then picks up and, well, reconciles.In order to do that, a few changes to previous invariants were necessary:
external_id
. That change required me to get rid of our batch-insertion/update logic that we used for changesets in the Store
. But that's alright, since we didn't use it anyway. See store.go
for that.PublicationState
and a ReconcilerState
in the API, see schema.graphql
.reconciler
ApplyCampaign
PublicationState
and ReconcilerState
to ListChangesets
applyCampaign
to split it up into more piecesdelta
is nicer to useCloseOpenChangesets
to the reconcilerresolver_test.go
SyncChangesets
to the reconciler (which will require making title
and body
on changeset nullable in the API since tracked changesets can then exist in an unsynced state) https://github.com/sourcegraph/sourcegraph/issues/12645
UpdateChangesets
, CreateChangesets
(note: plural!) methods