Campaigns: 3.18 Tracking Issue

[mrnugget]

Plan

The main goals for this iteration are:

• Add support for Gitlab to campaigns (Adam)
• Implement the campaigns workflow as documented in update docs for new campaign flow #10921 (Erik, Thorsten)

Both tie back to our OKR-based overarching goal to release campaigns as a non-feature-flagged, non-beta feature and get N customers using it to create campaigns.

Implementing Gitlab support is the result of multiple customers asking for it. Implementing the new workflow is the result of usertesting with Sourcegraph colleagues.

The first one should increase the number of customers trying out campaigns, the second one should make it easier for all customers to get started with campaigns and actually create campaigns.

Availability

Period is from June 22nd to July 17th (20 days). Please write the days you won't be working and the number of working days for the period.

• @mrnugget: 17d (Not working 6-8th July )
• @eseliger: 20d
• @LawnGnome: 19d (Canada Day 1st July)

Workload

@LawnGnome: 13.00d

• Cache diffstat for external changesets #11075 0.5d
• Clearer error message for improper JSON escape sequence in src actions scope-query #10541 0.5d 🐛
  • Update jsonx dependency #233 🐛
• Support GitLab in campaigns #11586 12d
• campaigns: spurious Percy failures caused by the landing page video #12170 🐛
• campaigns: GitLab webhook support #12171 2d
• CODEOWNERS: campaigns should own docs #12218

@eseliger: 4.50d

• Frontend: New campaigns flow #10986 8d
• YAML support for action definitions #11589 1d
• Use paginated search in src-cli to fetch repositories for campaigns #11587 1d 🕵️
• Don't put campaigns marketing page on dotcom behind auth #11501 0.5d
• Allow previewing of changesets for unsupported code hosts #11193 1.5d
• Remove hard distinction between manual and patchset campaigns #10984 0.5d

@mrnugget

• Backend: New campaign flow #10985 12d
• Replace "automation" feature flag with "campaigns" toggle and remove configuration flags #10713 1d 🛠️
• Creating larger campaigns using src-cli fails with 413 #9202 0.5d 🐛
• Make the verbose-mode ("-v") UI the default UI for src action exec #224
• Enable Campaigns by default (with write-access only for admins) #11621
• Implement missing bits in CampaignSpec/ChangesetSpec resolvers #12247
• Delete expired CampaignSpecs and ChangesetSpecs #12210
• Implement ChangesetSpec resolver and validation of specs #12092
• New campaigns flow: implement moveCampaign mutation #12049
• Add a basic implementation of the applyCampaign mutation #11934
• Add createCampaignSpec/createChangesetSpec mutations #11813
• Add GraphQL resolvers for CampaignSpec/ChangesetSpec #11733
• Add CampaignSpecs & ChangesetSpecs tables, type definitions and campaigns.Store support #11711
• Check that $VERSION is in MAJOR.MINOR.PATCH format in release.sh #227

@ryanslade: 2.00d

• src actions exec can cause frontend to be OOMKilled #10540 2d 🐛

Legend

• 👩 Customer issue
• 🐛 Bug
• 🧶 Technical debt
• 🛠️ Roadmap
• 🕵️ Spike
• 🔒 Security issue
• Pull Request

[LawnGnome]

Weekly update: 2020-06-15 to 2020-06-19

Last week, I worked primarily on finishing out the work to cache diffstats for external changesets. While I didn't quite get this merged by the end of the week, it feels like it was extremely close, and should be merged early this week.

Additionally, I worked on surfacing the alerts we get from Sourcegraph when a search fails in src-cli, complete with shiny colours. Again, this didn't quite get merged due to time zones, but should be merged on Monday morning.

[mrnugget]

Weekly update: 2020-06-15 to 2020-06-19

Besides multiple interviews and grading coding exercises, my main focus was providing feedback on https://github.com/sourcegraph/sourcegraph/pull/10921 and planning 3.18.

This week I'll try to implement the API schema proposed in #10921 to try to see how the pieces fit together — in sourcegraph/sourcegraph and src-cli.

[mrnugget]

Weekly Team Update: 2020-06-15 to 2020-06-19

cc @nicksnyder

What work did the team do last week?

Finishing up the work for 3.17 and planning 3.18. The main goals for campaigns in 3.18 are:

• Add support for Gitlab to campaigns (Adam)
• Implement the campaigns workflow as documented in update docs for new campaign flow #10921 (Erik, Thorsten)

How does that work connect back to the team’s OKRs and roadmap?

Our main goal is to release campaigns as a non-feature-flagged, non-beta feature and get N customers using it to create campaigns.

Implementing Gitlab support is the result of multiple customers asking for it. Implementing the new workflow is the result of usertesting with Sourcegraph colleagues.

The first one should increase the number of customers trying out campaigns, the second one should make it easier for all customers to get started with campaigns and actually create campaigns.

For each OKR and roadmap item, is the team on track? The answer should be of the form:

I think we are at a slight risk of not reaching this goal in Q2 because we're taking half a step back to get the campaigns workflow right and then take two steps forward. The result is that we're at risk of reaching the goal this quarter, but our chances to reach it increase, because we're making it easier to use and create campaigns.

What did the team work on last week that wasn’t originally planned? Why?

Nothing that I'm aware of.

What pain is the team experiencing?

• Tech debt: We now have multiple "store" implementations in our codebase: db, campaigns.Store, repos.Store, codeintel.db. They're all following the same pattern, except db, but db is the only one with authz/authn support. The result is that in our campaigns package, we now use repos.Store, campaigns.Store and db.Repos. Confusing. I've already talked to Eric Fritz and Tomás about this and I want to do a mini-spike to see how much work it would be to merge all stores into one.
• Quinn in his role as PM is overloaded. But we're all aware of this, which is why we're looking for a dedicated campaigns PM, just wanted to mention this for completeness and because it came up in the sync.

[eseliger]

Weekly update: 2020-06-15 to 2020-06-19

Last week, I spent most time on interviews, planning 3.18 and investigating a performance issue that leads frontend to go OO.

This week I am going to finish up yaml support and clear out the small tasks I have assigned for this iteration, so I have plenty of room once the frontend work for the new campaigns flow can be started.

[mrnugget]

Weekly update: 2020-06-22 to 2020-06-28

Last week, after removing then-unneeded code, I started implementing the API and database layer for https://github.com/sourcegraph/sourcegraph/pull/10921. That already yielded a lot of feedback and insight into how we can structure and model certain things. Since the new campaigns workflow replaces a lot of code, @eseliger and I decided to use a single PR as a merge-target for all our new-workflow related PRs.

I've also dug a little bit into our dbtesting and other DB-testing-related packages to see if we can speed things up and/or unify them. Besides that: ton of interviews!

This week looks like it'll also have its fair share of interviews, but besides those my goal is to finish the database layer required for the new campaigns workflow. I also have some thoughts on how to build the reconciler/controller that turns changeset/campaign specs into "actual" things, and I might try to prototype some of that, although I won't finish it this week and there's still some question marks around how things will work in detail that we need to figure out first.

[eseliger]

Weekly update: 2020-06-22 to 2020-06-28

Last week

besides a couple of interviews, I finished yaml support in src cli, worked on frontend testing toward the frontend testing OKR by adding better serializers for enzyme and migrating the campaigns codebase to utilize those in this PR and cleaned-up and tested on edge-cases with the removal of the manual campaigns distinction here. I also started working on a prototype using search pagination in src-cli, and wrote my writeup of that today.

This week

I am going to work on enabling collecting changesets for unsupported codehosts and will look into the new GraphQL API and UI, and see what tasks we can derive from it, so I can make my placeholder issue #10986 more precise.

[LawnGnome]

Weekly update: 2020-06-22 to 2020-06-26

Last week was a good merging week for me: the PRs to cache external changeset diffstats and surfacing search alerts in src-cli both landed.

With those out of the way, I spent most of my week working on implementing GitLab support. The ticket with the scope of this is in #11586, and the draft PR is #11757. I made good progress, and the draft PR is operational (if poorly tested right now) for everything except changeset events and webhooks. Between those and improving the test coverage, I expect this will hit ready for review status late this week, assuming there are no unexpected icebergs.

I'm also trying to put a little effort in each week to improving the src-cli experience for campaign users: last week I implemented support for rendering pretty JSON errors. While campaigns will be moving to YAML soon, this also improves error messages for external service and site configuration updates, and provides a template for how I'd like to render YAML errors when the time comes as well.

This week, my focus will be on finishing the GitLab work and merging the src-cli JSON error change. If all goes well, this should allow me to pick up some more work this iteration!

[mrnugget]

Weekly Update 29 June 2020

cc @nicksnyder

What work did the team do last week?

We started the iteration by finishing some smaller tasks and then making progress on the big items in our tracking issue:

• Erik investigated the feasibility of paginated for use in campaigns, added YAML support to src-cli and added support for "unsupported" codehosts to campaigns.
• Adam improved the user-friendliness of src-cli error messages by giving precise information in JSON parse errors (by fixing issues and extending our jsonx library!) and started working on adding Gitlab support to campaigns.
• I (Thorsten) fixed a minor issue in src-cli, added more things to RFC179, and then started implementing the API and database layer for the new campaigns workflow.

How does that work connect back to the team’s OKRs and roadmap?

See the previous weekly update.

For each OKR and roadmap item, is the team on track? The answer should be of the form:

No big changes between last week's update and this one (the previous weekly update) except that Adam's thinks there's a chance that Gitlab support might be faster than we thought it would be and that he could start helping out with the new campaigns workflow earlier than we thought.

What did the team work on last week that wasn’t originally planned? Why?

Nothing major. Adam had to fix multiple things in jsonx to fix things in src-cli, but since the ticket itself was planned, I'm not sure this would fall under unplanned things. I invested some time to try to make our dbtesting package faster, still haven't finished it, but want to do a timeboxed hack session with Keegan on this.

What pain is the team experiencing?

• After the issue of tech debt was raised in Slack and last week's company update, I think we're all a bit more conscious of tech debt that has accumulated and try to fix it. That's not a real "pain", but of course no tech debt is better than tech debt.
• Same as last week: we're in need of a dedicated PM, because Quinn has too much on his plate. We're not at the point yet where we are blocked by lack of input from product side, but there are some open questions accumulating.
• I (Thorsten) am personally not 100% happy with having to keep a long-living branch (see my update here for context). Rebases are painful, yes, but on top of that: when I find something that I want to clean up or could improve (tech debt) the incentives are now aligned against me, because large sweeping changes would make the rebases and future merge harder and harder. Reviews would also be harder. And ever since Beyang's tweet about code reviews being bottlenecks I'm actively thinking about this.