Skip to content

Rush

Jump to bottom
praveenkuttappan edited this page Jan 25, 2022 · 4 revisions

rush update

There are 3 "levels" of the rush update command, which is used to update the pnpm-lock.yaml file:

  1. rush update: Only makes the minimum updates needed to satisfy the package.json files.
  2. rush update --recheck: Additional updates to ensure the pnpm-lock.yaml file is consistent with the package.json files.
  3. rush update --full: Updates all dependencies to the latest SemVer-compatible version.

This table summarizes the differences between rush update and rush update --recheck. Given a particular source change, is pnpm-lock.yaml updated?

rush update rush update --recheck
Add new dependency yes yes
Add existing dependency no yes
Remove dependency no yes

If a new dependency (not use by any other project) is added, both commands will update pnpm-lock.yaml. But if an existing dependency is added or a dependency is removed, then only rush update --recheck will update pnpm-lock.yaml. I believe this is by design and why both commands exist.

Current Workflow

Our current workflow is that developers run rush update as part of any PR which might update pnpm-lock.yaml. If a PR adds an existing dependency or removes a dependency, this change will not be reflected in pnpm-lock.yaml until a later time, when another PR adds a new dependency or runs rush update --full.

A "stricter" alternative would be:

  1. Developers are expected to run rush update --recheck in any PR that might cause updates to pnpm-lock.yaml.
  2. Our pipelines will also run rush update --recheck, and fail if any changes were detected (meaning the PR was missing the changes).

The upside to the stricter version is that pnpm-lock.yaml changes should always be in the same PR as the code changes. The downside is pnpm-lock.yaml will be updated more often, and developers may need to re-submit more PRs with fixes.

Upgrade to a newer version of rush

Here are the steps to upgrade to rush to a newer version

  1. latest rush version available here rush latest. Verify the change log for this latest version to see if there are any changes that can impact our build. For e.g. Check for any changes related to how dependent packages are identified when --to or --from is passed to rush command. Change log is available here rush change log

  2. commits from upstream main branch of azure-sdk-for-js repo and create a branch to make rush changes.

  3. rush.json in root directory of azure-sdk-for-js repository to update rush version to latest required version. Here is the link to rush version property rushVersion

  4. Run rush update

  5. Run rush build

  6. If build is successful for entire repo then

    a. Run recorded test for packages in few services

    b. Few options we usually pick - core, storage, event-hub, form-recognizer, identity, test-tools, one track2 management package

  7. Create a PR for this change in rush.json if all tests are successful

  8. Trigger one integration(live test) for at least one package against this change in addition to regular pipeline runs.

Additional steps:

  1. Check if any major change is done by rush in how they evaluate package dependency. For e.g. how --to or --from is evaluated. This information is available here.

  2. Also check for any new options supported by rush that may improve build time. These changes should only be done after discussing with JS team.

  3. As part of testing rush upgrade, following steps must be done to ensure new version is not impacting CI for azure-sdk-for-js.

    a. Identify a few services to compare previous build time with older rush version. for e.g. core, identity etc.

    b. Verify build time and number of packages rush identified as part of build job for previous rush version on a particular platform (for e.g., Ubuntu).

    c. Ensure that new rush version build exact same set of packages as part of build job and build time is not significantly changed on same platform.

Clone this wiki locally