a8n: Add a prototype campaign type to search & replace leaked NPM credentials.
Created by: mrnugget
This is a rough prototype that implements the first steps of #6852. I built this to illustrate how it can work with the current architecture and, more importantly, what we could change to make it more performant and robust.
Note to reviewers: Look at this by commits. I had to create one huge commit first that exposes types from the graphqlbackend
so I can access search
Shortcomings of this PR:
- The campaign type has to search again, even though we already searched for the tokens before constructing the
CampaignJob
s. Possible solution: persist theFileMatches
along withLineMatches
on theCampaignJob
in ajsonb
column. - The diff is created by hand and thus (judging by past "diff does not apply" experiences) very brittle. Possible solutions: shell out to
diff
/git diff
once we have "old file content" and "new file content" at hand, or use a library that constructs a diff in memory (so far, none of them were able to produce a working unified diff), or build a library that does this... - The search queries are constructed by concatenating strings. That can be brittle, since we concatenate the
scopeQuery
, a user-defined string, to our search terms. We're also missing "count:9999" here to make sure we get everything. Possible solutions: something along the lines of RFC 75 that proposes a more structured interface to search.
We now need to decide which one of these shortcomings is a blocker.
Update in this comment
Merge request reports
Activity
Created by: rvantonder
I built this to illustrate how it can work with the current architecture and, more importantly, what we could change to make it more performant and robust.
Is the intent to actually merge this PR, or is it just for comments, or possibly both? Would just help me to understand how to approach this PR.
Created by: mrnugget
Update on this: if @eseliger is fine with this, I would say that we go ahead and merge this and then refine and improve it in subsequent steps instead of the branch becoming stale.
In the next few days I'm going to look into points (1) and (2) from the original PR description:
- The campaign type has to search again. Solution I want to investigate: persist the FileMatches along with LineMatches on the CampaignJob in a jsonb column.
- The diff is created by hand. Solution I want to investigate: shell out to diff/git diff once we have "old file content" and "new file content" at hand.
Besides that, we can also switch to JSON Schema based validation in a follow-up PR, for this campaign type and comby.
Created by: codecov[bot]
Codecov Report
Merging #6893 into master will decrease coverage by
0.05%
. The diff coverage is0%
.@@ Coverage Diff @@ ## master #6893 +/- ## ========================================== - Coverage 39.16% 39.11% -0.06% ========================================== Files 1230 1230 Lines 63349 63436 +87 Branches 6038 6041 +3 ========================================== Hits 24810 24810 - Misses 36272 36359 +87 Partials 2267 2267
Impacted Files Coverage Δ web/src/enterprise/campaigns/detail/backend.ts 0% <ø> (ø)
enterprise/internal/a8n/campaign_type.go 21.87% <0%> (-22.43%)
enterprise/internal/a8n/service.go 14.89% <0%> (ø)
...rc/enterprise/campaigns/detail/CampaignDetails.tsx 0% <0%> (ø)