The changelog generator should parse multiple type comments from merge commit. #7171
Comments
|
This would be useful. Intuitively guys have been defining multiple types for their PRs since we started using the changelog generator. PS. The "get next version" release util will also need to be updated. |
|
If you really would like to introduce this change, we need to rewrite the whole engine that collects commits. Now we're using As a workaround, I prefer to make an empty commit directly after the merging one with the second prefix. git commit --allow-empty -m 'Fix: Whatever introduced in [hash: 7 or 40 characters].'If we go with the later one, we need to replace full hash with short hash and short hash with a URL to the proper commit on GH. Another solution that came to my mind is using a PS: Multiple BC and notes are parsed because single commit can break a lot of things. |
|
I didn't mention that |
That's a bummer :( But couldn't we use |
|
We can transform a single commit as an array that contains two commits. This is not a problem because we already modifying the single commit so we can do whatever we want with this. But other parts of the tool don't understand why it will receive the array instead of an object. If it fails here, other parts won't work properly. |
|
@pomek I didn't dig into internals - but I'm thinking about processing the I wonder if this would be a quick "fix" for this issue - probably we could parse string after |
|
There is no option to add another commit to the result array (of commits). That's the problem. Wherever we will define additional info for the virtual commit, we have no option to pass the virtual commit through the process line. |
|
Hm... I forgot about conventional changelog. So, I'd avoid hacking it or the way how we define commit messages (I don't like the proposal with Instead, if this is a limitation that we have, I'd rather see a GH hook which lints the proposed commit message. It can explain it to you how to format your commit message if you did a couple of things at once. |
mlewand
added
type:improvement
|
After merging ckeditor/ckeditor5-dev#640, multi-messages in a single commit will be supported. |
Feature (env): Support for multi-entries messages in the single commit and scoped changes. Closes [ckeditor/ckeditor5#7207](ckeditor/ckeditor5#7207). Closes [ckeditor/ckeditor5#7171](ckeditor/ckeditor5#7171). See https://ckeditor.com/docs/ckeditor5/latest/framework/guides/contributing/git-commit-message-convention.html. Feature (env): Added new utils that help to collect commits, parsing them, and generating the changelog. * The util for generating changelog from commits (those must be specified as an argument). See `/lib/release-tools/utils/generatechangelog.js` * The util for collecting commits. See `/lib/release-tools/utils/getcommits.js` * The util for suggesting new version based on commits. See `/lib/release-tools/utils/getnewversiontype.js` Feature (env): Task `generateChangelogForSinglePackage()` supports new options: `from` - a commit or tag for collecting commits since the last release, `highlightsPlaceholder` - whether to add "Release highlights" placeholder in the changelog, `collaborationFeatures` - whether to add a URL to collaboration features changelog. Fix (env): The `getChangedFilesForCommit()` util filters files returned by the Git command. It won't return an empty string anymore. Other (env): Commits in the changelog will display the word `commit` instead of the first 7 characters from the commit's hash. In big repositories (the number of commits is huge), 7 characters are not unique anymore. Other (env): `Closes` references will be merged into a single entry. Github does not support such references (`Closes x, y`) but it can be simplified during the commit's transformation. Other (env): The `provideVersion()` util from `lib/release-tools/utils/cli.js` allows disabling returning `skip` version by setting its option `disableSkipVersion` to `true`. Other: Removed `lerna` and all its files from the project. Now the release process is handled by our tools. The entire repository will follow the same rules as `ckeditor5.` Read more: https://ckeditor.com/docs/ckeditor5/latest/framework/guides/support/versioning-policy.html. MAJOR BREAKING CHANGES (env): Removed `generateChangelogForSubPackages()` task. Use `generateChangelogForMonoRepository()` instead. MAJOR BREAKING CHANGES (env): Removed `generateChangelogForSubRepositories()` task. Use `generateChangelogForMonoRepository()` instead if your repository is a monorepository. MINOR BREAKING CHANGES (env): The util `getPackagesPaths()` does not check whether packages are defined as `dependencies` in `package.json` in the main repository. MINOR BREAKING CHANGES (env): Task `generateChangelogForSinglePackage()` does not accept options: `newVersion`, `disableMajorBump`, `isInternalRelease`, `indentLevel`, `useExplicitBreakingChangeGroups` anymore. The task should be used for generating the changelog for the single repository. MAJOR BREAKING CHANGES (env): Removed `generateSummaryChangelog()` task. MINOR BREAKING CHANGES (env): Removed `hasMajorBreakingChanges()` and `hasMinorBreakingChanges()` utils from `/lib/release-tools/utils/changelog.js` helper. MINOR BREAKING CHANGES (env): Removed `getSubPackagesPaths()` util. MINOR BREAKING CHANGES (env): Removed the `getNewReleaseType()` util. Use `getCommits()` and `getNewVersionType()` instead. MINOR BREAKING CHANGES (env): Removed support for the `NOTE` type of commit's notes. MINOR BREAKING CHANGES (env): Moved all utils from `/lib/release-tools/utils/transform-commit` to `/lib/release-tools/utils`. MINOR BREAKING CHANGES (env): Renamed `getSubRepositoriesPaths()` util to `getPackagesPaths()`.
|
Introduced in ckeditor/ckeditor5-dev#640. |
The general rule of a thumb is that a merge should only introduce one change (atomic, precise, other blah, blah) but there are times that this would be useful.
Allow us to create merge commits like this:
ATM only multiple
BREAKING CHANGE:are parsed (if I get this correctly).The text was updated successfully, but these errors were encountered: