Skip to content

Auditing and merging dependabot Pull Requests

Jump to bottom
Howard Edwards edited this page Sep 3, 2024 · 1 revision

Auditing and merging dependabot Pull Requests

Configuration

The current configuration is located at .github/workflows/dependabot.yml. It runs on the first day of each month at 10:00am UTC and the Pull Requests' titles are prefixed with Infrastructure. Another identifier of these PRs is that the following labels are automatically applied:

  • dependencies
  • javascript (if a npm package is being updated)
  • github_actions (if a github-actions version is being updated)

To query all open dependabot PRs, you can use the following label:dependencies + title:Infrastructure query (although other PRs not created by dependabot could also be a part of this query). Alternatively:

Auditing

Generally, review the Release notes or Changelog included in the top comment of the dependabot's PR to understand if any potential breakage has been included depending on how w3c/aria-practices uses the package.

NOTE: Because it only extracts a set number of a lines for the most recent versions, there may be a chance that an important version update has been missed so would recommend going directly to the package's releases or CHANGELOG page to review the changes in depth if needed.

Example: PR title: Bump packageA from 12.3.3 to 12.5.1 and versions 12.3.4, 12.4.0, 12.4.1, 12.4.2 and 12.5.0 has has been released between the versions being updated. But 12.4.0 may have included some breaking change but isn't displayed in the small snippet shown with the PR.

By Version

Patch Version Bump (#.#.Z)

Very light checks are usually applied to these and it's reasonable just verifying the functional requirements of how the package is being used hasn't been disrupted.

Minor Version Bump (#.Y.#)

Light to moderate checks can be applied here (depending on the package) and can mainly be a verification of functional stability.

Major Version Bump (X.#.#)

In depth checks should always be applied here. It's becomes even more important in the cases where this a package that directly affects the regression testing (ava, geckodriver, etc.) or the linting requirements (eslint, stylelint, etc.) because more often than not, it will mean a separate PR has to be created that bumps the version as well as making code changes.

By Dependency

Not all packages are the same; some packages could pull everything down!

Regression test runner dependencies

Given the components created by the APG are meant to guide web component authors where applicable, a lot of its confidence is had on the validity and the repeatability of the results in their extensive testing suite. As such, the dependencies which are responsible for doing just that should be given a high priority when during any dependency reviews. Running npm run regression to verify any changes for these dependencies will be very important. Namely:

  • ava
  • geckodriver
  • selenium-webdriver

Content generation dependencies

Several files are constantly re-generated in APG such as content/index/index.html and files in content/about/coverage-and-quality. So making sure these are consistently regenerated would mean paying special attention to what the following dependencies are doing:

  • cheerio
  • glob
  • htmlparser2
  • node-fetch

Linting dependencies

Continue verifying linters are doing what they need to with npm run lint mainly. Dependencies:

  • cspell
  • eslint
  • eslint-*
  • htmlhint
  • stylelint
  • stylelint-*
  • vnu-jar

Merging

  • If the dependabot PR seems suitable, a Squash & Merge can be immediately done. If there is any management you'd like to do with a dependabot PR after it's been created as well, here are some useful commands.
  • If the dependabot PR would require additional changes, create a different PR also with the title prefixed with Infrastructure: and make the appropriate adjustments. Request the relevant PR reviewers before merging. Recent example here.
  • Some dependency changes are more appropriate being done together such as the eslint-* related changes or the test runner dependencies so also creating a separate PR to do those together would be appropriate. Recent example here.
Clone this wiki locally