DEV Community

Kinga
Kinga

Posted on

Rush and changelog generation - Part 1

This really breaks my heart πŸ’”... Rush is not supporting conventional commits.
In fact the whole process of committing code and generating changelogs is using unique approach.

The process flow by Rush

If you work on libraries that get published as NPM packages, your repo probably requires you to include change log entries as part of your PR. You will know because your PR build will fail on the rush change --verify step.
To write change logs, first commit any pending work to Git. Then type rush change from anywhere under your repo working folder. This command will examine your Git history to determine which project folders have diffs. Based on that, it will prompt you to write a change log entry for each one. Each change log entry gets stored in a separate file under common/changes. You should add and commit these files to Git.

Later, Rush's automated publishing workflow will inspect these files to determine which packages need to be published. It will delete the files and copy your messages into the package's CHANGELOG.md file.
Source: Everyday commands / rush change

A look under the hood

OK, let's see what's happening here.
Imagine you have a spfx-utils solution with some code in UtilsLibrary.ts file.

  1. Switch to a new features/cc branch: git checkout -b features/cc git push --set-upstream origin features/cc
  2. Edit the code in a UtilsLibrary.ts file, belonging to the spfx-utils solution
  3. Commit changes: git commit -am "feat(date): Add getCurrentTime()"
  4. Run rush change rush change resultsThe first thing I see is that rush change compares my changes to the master branch. It's actually documented:Image description
  5. To compare the features/cc to its remote, specify --branch parameter: rush change -b origin/features/cc.TransparentpixelAlso, rush change doesn't really care about the commits. It asks for a change description and change type, leaving it up to the developer to decide on the version bump. It won't even display the previous commits (which maybe sometimes is not a bad idea πŸ˜‰ ). rush change generates common\changes_branchname-timestamp.json_ file: Image description If you press Enter to skip changes description, a change file with a change type none will be created.
  6. Rush recommends including rush change --verify in the PR process to ensure that developers generate change files. Let's see what will happen now, that the files are created.
  7. rush change --verify --target-branch origin/features/cc returns Image description
  8. This is because files created by rush change must be committed. Run: git add common/changesgit commit -m "docs: Add changefile(s)"
  9. Check again: rush change --verify -b origin/features/cc. All is good: rush change verify results
  10. Add another function to the UtilsLibrary.ts file.
  11. Commit changed files: git commit -am "feat(date): Add getCurrentDate()"
  12. What would happen if I run rush change --verify -b origin/features/cc again? Will rush detect the commits I made since the last rush change? Nope: rush change verify results

Summary

  • If you don't specify the branch parameter (-b or --target-branch), the checked out branch is compared against the "master" branch.
  • Rush will NOT generate changelogs based on your commits.
  • Rush recommends using rush change files to generate change files which are later used to generate changelogs.
  • Rush does NOT support conventional commits and developers needs to decide on the version bump (major/minor/patch).
  • Developers have to commit change files. Otherwise rush change --verify will fail.
  • rush change --verify doesn't check if there were any commits AFTER already existing change files were generated. After running rush change (and committing the change file), developers may add new commits and rush change --verify will not complain.

Top comments (0)