Skip to content

Monitoring Batch Changes a.k.a Invariants

Created by: eseliger

Problem to solve

The main use case today for batch changes is to make one-off changes. However, we believe there's value in allowing long-running batch changes, that either run on a schedule or are triggered when a certain code pattern is introduced in the codebase.

Batch changes could be either:

  • Triggered from a Code Monitor, using either the same search query as the batch spec or a modified
  • Run over repos on some schedule to ensure a particular pattern isn't found

An example of a use case is CVEs: we could have a "common CVEs" suite where we collect batch specs for common CVEs and can notify code owners about existing problems and suggest a 1-click fix. "log4j vulnerable package found, this is the diff. Looks good?"

This feature is pending validation and impacts our positioning. In particular we need to:

  • research in which case this is better than a linter or a static analysis tool, and doing this pre-commit.
  • study the dependency management use case. It is not what Batch Changes is supposed to be good at, but we hear otherwise from some customers.

Measure of success

TBD - some usage metric

Solution summary

  • Allow Batch Changes to run recurringly or triggered by Code Monitoring.
  • Make sure long-running batch changes are supported
  • Provide a workflow for repo owners to disable this for their specific repository

Artifacts:

  • TO DO, this needs a PD

What specific customers are we iterating on the problem and solution with?

Impact on use cases

  • Fixing security vulnerabilities
  • Code health, in particular:
    • a code checker / linter use case: preventing a bad code patter to be introduced in the codebase"
    • a dependency management use case: we have reasons to believe that using batch changes for dependency management has some advantages over dependabot. This needs to be further studied.
    • research other use cases

Delivery plan