ericmatthys / grunt-changelog Goto Github PK

Hej,

I love to have my commit info in the following format:

• b5873bd - 2014-07-03: i18n for dataTables.
• be90085 - 2014-07-03: Enhance styling of bootstrap dataTables.

which is accomplished with the following git log command:

git log --pretty="* %h - %ad: %s" [tag]..[tag] --no-merges --date=short

Which might be not everyones flavor. So it would be cool to make this configurable via an option.
I guess I’m going to prepare a pull request for that feature.

Is this by design? Since grunt-changelog by default uses the --no-merges option, why not make this a default for logArguments, too?

See tasks/changelog.js @ lines 176...183.

Found this when running the latest grunt-changelog:

Deprecation warning: moment construction falls back to js Date. This is discouraged and will be removed in upcoming major release. Please refer to moment/moment#1407 for more info.

Of course, the arguments passed to moment are non dates, e.g. 'commit' and 'v1.1.2'.

Perhaps grunt-changelog should try/catch moment(mightbeadatetime)?

Was trying to update the version that I have from npm, but it was still pulling the old 0.1.4 version.

In order for humble me to have its will, and also to be able to generate the changelog that I want, I need single line parsing.

The rationale behind this being that

• each line prefixed by a hyphen in my commit message refers to a specific change and may optionally reference an issue including also the type of change, e.g. api(change), deprecates, feature, fix(es) and so on
• something which will be singled out by pretty=%s, but with the new logArguments in place, I can use --pretty=%B and everything is fine
• each non prefixed line can be silently ignored and must not be included in the changelog

Without this option I will not be able to gather non issue related changes in the changelog as it

a) would make the resulting regexp overly complex, and
b) would not even be possible to achieve with regexp alone

Therefore, I propose another option to grunt-changelog, namely

• multiline : true (default) | false

On true, grunt-changelog will expose its current standard behaviour.

On false, grunt-changelog will use a different parser for the changelog that will run tests against the section regexps line by line instead of applying them globally on the whole of the log returned from git/passed in as a parameter.

Please note that this requires #39 to be merged as the following PR will build on that.

That way, one can use changelog with tags and also can use it programmatically, for example:

As of now it is near impossible to get the changelog for the first tag, say, v0.0.1 where there is a history of commits before the initial release.

With the patched version of grunt-changelog I am using, I am now able to do this in my gruntfile

100 determinePreviousTag = (grunt, tag, callback) ->
101 
102     grunt.util.spawn { cmd : 'git', args : ['tag'] }, (error, result) ->
103 
104         if error
105 
106             grunt.fail.fatal(error)
107 
108         tags = result.toString().split('\n')
109 
110         index = tags.indexOf(tag)
111 
112         previousTag = null
113         if index > 0
114 
115             previousTag = tags[index - 1]
116 
117         callback previousTag

to determine the previous release version tag. Now, for the first release tag that would be null.

I've tried convincing grunt-changelog that I only need the before but it always determined that this was a date range and thus generated the wrong output.

In a wrapper task I am using this

325     grunt.registerTask 'update-changelog', ->
326 
327         latebind grunt
328 
329         done = this.async()
330 
331         pkg = grunt.config.get 'pkg'
332         tag = "v#{pkg.version}"
333 
334         determinePreviousTag grunt, tag, (previousTag) ->
335 
336             changelogTask = 'changelog:default'
337 
338             if previousTag is null
339 
340                 changelogTask += ":commit:#{tag}"
341 
342             else
343 
344                 changlogTask += ":#{previousTag}:#{tag}"
345 
346             grunt.task.run changelogTask
347 
348             done()

to programmatically adjust the changelog configuration, namely setting either the commit option or the before and after option.

In return this will then run

  git log v0.0.1 --pretty=format:%s --no-merges

for the first tag instead of

  git log --after=<valid-date> --before=<invalid date containing NaNs> ...

For subsequent tags it will run

  git log v0.0.1..v0.0.2 --pretty=format:%s --no-merges

and so on.

See the upcoming pull request below.

I was wondering whether allowing the user to pass in additional data to the template would be of any value, e.g.

options: {
   data: {
      package: packageObject,
      ...
   }
}

Since that data could be collected dynamically from e.g. the package.json file, for example a list of contributors, the author and so on, it would allow the user to customize the change log even more.

What do you think?

The templating functionality is great with this, and partials are a huge step in customizing the output. Taking this a step further, it would be nice to also allow for helper functions to be configured for the templates.

One example of this is to stringify data being written to the log. I am creating both a text and JSON changelog. The JSON is for other services to be able to easily parse. Using a helper, I can be sure that my output is JSON-safe. Here's an example of my current implementation:

changelog: {
    portal: {
        options: {
            after: 'v<%= package.version %>',
            partials: {
                features: '{{#each features}}{{> feature}}{{/each}}',
                feature: '[FEATURE] {{this}}\n',
                fixes: '{{#each fixes}}{{> fix}}{{/each}}',
                fix: '[BUGFIX] {{this}}\n'
            }
        }
    },

    // JSON version for easier parsing
    extension: {
        options: {
            after: 'v<%= package.version %>',
            dest: 'changelog.json',
            template: '{"fixes": [{{> fixes }}], "features": [{{> features }}]}',
            helpers: {
              toJSON: function(object){
                  return new Handlebars.SafeString(JSON.stringify(object));
              }
            },
            partials: {
                features: '{{#each features}}{{> feature}}{{#unless @last}},{{/unless}}{{/each}}',
                feature: '{{toJSON this}}',
                fixes: '{{#each fixes}}{{> fix}}{{#unless @last}},{{/unless}}{{/each}}',
                fix: '{{toJSON this}}'
            }
        }
    }
}

Output:

{
    "fixes": ["Fixed issue with \"stuff\" not working"],
    "features": ["Update notification feature", "Another feature"]
}

tl;dr

Git Tags like 2.6.19 are treated as date (2019-02-06) 😬

We are using Git tags which are equal to the version number within our package.json file to handle relases.

Therefore our settings for changelog Grunt task are the following to generate a simple changelog with sections for every version (release).

changelog: {
  release: {
    options: {
      fileHeader: '# Changelog',
      logArguments: [
        '--pretty=%h - %ad: %s',
        '--no-merges',
        '--date=short'
      ],
      after: '<%= pkpCopy.version %>',
      dest : 'CHANGELOG.md',
      insertType: 'prepend',
      template: '## Version <%= pkg.version %> ({{date}})\n\n{{> features}}',
      featureRegex: /^(.*)$/gim,
      partials: {
        features: '{{#if features}}{{#each features}}{{> feature}}{{/each}}{{else}}{{> empty}}{{/if}}\n',
        feature: '- {{{this}}} {{this.date}}\n'
      }
    }
  }
}

In one project we encountered the following error while running our release task:

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory
Abort trap: 6

Running Grunt in verbose mode showed that the git log params are weird:

git log --pretty=%h - %ad: %s --no-merges --date=short --after="2019-02-06T00:00:00+01:00" --before="2015-05-06T19:57:06+02:00“

Instead of:

git log 2.6.19..HEAD --pretty=%h - %ad: %s --no-merges --date=short

And that’s the reason of this bug:
We reached a version number that »looks« like a date 😳
Because 2.6.19 is interpreted as 2019-02-06

That is because the changelog task is trying to be too clever.
The after and before options are taking date strings, commit SHAs and Git tags and need to decide the how to handle them.
See: https://github.com/ericmatthys/grunt-changelog#optionsafter

Here is the decision making process:
https://github.com/ericmatthys/grunt-changelog/blob/master/tasks/changelog.js#L42-L43

Moment.js is used to check if the string is a valid date. 💣 💥

My idea how to fix that is to check if the string is a valid semver versionnumber before checking if it is a valid date.

It would be really great if there was a preset template for building Jenkins compatible change logs: https://wiki.jenkins-ci.org/display/JENKINS/Change+log

I would like to use the change option to add either [FEATURE] or [BUGFIX] in front of the {{change}}. How can I go about doing this?

I am trying to use the custom ranges feature and every way I try, I can't get it working.

I tried using the tags, dates, and commits. Each produces the same error (below).

Running this command: grunt changelog:dist:a2f5c3901c5:056c9dc7397

Produces

Security context: 27A25599 <JS Object>
    2: getChanges(aka getChanges) [myworkspace\node_modules\grunt-changelog\tasks\changelog.js:~76] [pc=34EC8F64] (this=27A08099 <undefined>,log=19F9852D <an Object with map 3DFA1E19
>,regex=19AC1FD1 <JS RegExp>)
    3: getChangelog(aka getChangelog) [myworkspace\node_modules\grunt-changelog\tasks\changelog...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory

I am running 0.3.2 of grunt-changelog and both of those commits do exist in my repo. I am able to run grunt-changelog if I omit any before or after options either in the config or on command line, so it works without that stuff.

I would love the ability to have the change log generate all changes between one tag and the current code, or between 2 tags.

e.g.
after: 3.1 OR after: 3.1, before: 3.1.3

Having a commit message like so

• added X
• removed Y

using git --pretty=format:%s will collapse existing lines into a single line like so

• added X - removed Y

Using %B instead will preserve the original layout of the commit message.

Hej, one more thing 😘

It would be awesome to make it possible to define a file header like the follwing example.

option.fileHeader: '# Changelog'

Best regards,
Michael

Please make this point to tasks/changelog.js instead.

The reason for this being that I want to hide certain tasks as they will not work as expected in my build process which targets both NPM and Meteor package builds.
As such I need to require('grunt-changelog') and then late bind the task associated with it.
Having require returning me your Gruntfile renders this task unusable for me.

I wanted to just overwrite the main template, but leave the change and empty templates as the default.

templates: { main: 'v1.0 :: {{date}}' }

This gave me the error Fatal error: Cannot call method 'replace' of undefined

After adding the other templates change and empty, it worked correctly.

Hi, I wonder if you are still actively developing this grunt task and if it were possible to have the following PR's integrated into master and possibly also the next NPM release:

• #22, #23, #26, #27

TIA!

While working on #24, I found that while all existing test cases do actually work, the underlying regular expressions, especially the default ones, generate rather random results. See below.

Considering the following output of regular expressions and their respective matches

regex: "/^(.*)fixes #\d+:?(.*)$/i":"Fix 1 2 3."
regex: "/^(.*)fixes #\d+:?(.*)$/i":"Fix 4 5 6."
regex: "/^(.*)fixes #\d+:?(.*)$/i":"Fix 7 8 9."
regex: "/^(.*)closes #\d+:?(.*)$/i":"Feature 1 2 3."
regex: "/^(.*)closes #\d+:?(.*)$/i":"Feature 4 5 6."
regex: "/^(.*)closes #\d+:?(.*)$/i":"Feature 7 8 9."

it would seem that the matches produced by the default regular expressions are lucky at best.

Perhaps reworking these regular expressions would be a wise move?

Hi there,

awesome Task.
The only thing I’m wondering about is the usage of Entities in the generated Changelog.

- Add "es3" to js.hintrc to prevent problems with trailing commas up to IE8. 

This doesn’t make sense in my use case which is generating a simple text file. Is it possible to make this configurable?

because changelog is a multitask the config object needs to contain at least one task like so (the extra object "log{}"):

grunt.initConfig({
    changelog: {
        log: {
            options: {
                after: '2013-03-01',
                before: '2013-03-14'
            }
        }
    }
})

With the current example code it will just fail without an error.
This took me a while to figure out.

Thanks a lot for the otherwise great plugin! :-)

I am currently working on a patch that will allow the user to add custom sections to the changelog, e.g.

Release v0.2.1 (2014-11-10)

API Changes:

 - Tool#extend now expects three parameters instead of just one

API Deprecations:

 - Tool#shutdown is now deprecated, use Tool#quit instead

New Features:

 - ...

Bug Fixes:

 - ...

Miscellaneous:

 - implemented more test cases
 - integrated Travis CI
 - ...

and so on.

I will pour you in a pull request as soon as it is done. Of course I will try to make it backwards compatible so that existing build configurations need not be changed.

Is it possible to append to the destination file instead of overwriting it?

Hi there,
I was unable to see an option to add a list of changed files under each commit. Is this possible?

Hi,
I installed this module as described to my package.json: "grunt-changelog": "^0.3.0",

Usage in Gruntfile.js:

    changelog: {
      sample: {
        options: {
        }
      }
    }

A run produces this console output:

(node) warning: Recursive process.nextTick detected. This will break in the next
 version of node. Please use setImmediate for recursive deferral.

util.js:35
  var str = String(f).replace(formatRegExp, function(x) {
                      ^
RangeError: Maximum call stack size exceeded

Does anyone has an idea what could be the problem here and how to solve it?

My options:

options: {
            featureRegex: /^ICPIM-\d+.*?:((?!fixed).*)/gim,
            fixRegex: /^fix(ed)? ICPIM-\d+:?(.*)/gi,
            dest: 'CHANGELOG.md',
            after: '2014-02-13',
            before: '2014-03-25',
            template: '## <%= package.version %> / {{date}}\n\n{{> features}}{{> fixes}}' ,
            partials: {
                features: '{{#each features}}{{> feature}}{{/each}}',
                feature: '- [FEATURE] {{this}}\n',
                fixes: '{{#each fixes}}{{> fix}}{{/each}}',
                fix: '- [FIX] {{this}}\n'
            }
        }

Notice that the fixRegex has 2 matches in it, so the output of my fix shows - [FIX] undefined Increased pagesize

See the undefined at the beginning? How can I tell it to only match the 2nd match?

The current/old test fixtures include newline characters and other content that are actually lost when running git log --pretty=%s.

Here is an example of git log --pretty=%s --no-merges vs git log --pretty=%B --no-merges

1 Bump Version from 0.2.2  to 0.3.0 and add a version badge                                  |  1 Bump Version from 0.2.2  to 0.3.0 and add a version badge
  2 Fix travis build by installing grunt cli globally                                          |  2 
  3 Update dependencies                                                                        |  3 > Version Badge provides a consistent way for the npm community to learn about the npm pac  4 Add .travis.yml and status badges to README                                                |    kage associated with a particular Github repository and other documentation pages. Once th
  5 Cleanup package.json                                                                       |    e package owner adds this badge to their README file, it will inform and link all visitors
  6 Add contributing guidelines                                                                |     to the latest version of that package.
  7 Add new option `fileHeader`                                                                |  4 
  8 Add new option `logArguments`                                                              |  5 Fix travis build by installing grunt cli globally
  9 Change default partials rendering the commit messages                                      |  6 
 10 Add .editorconfig                                                                          |  7 Update dependencies
 11 Update readme.                                                                             |  8 
 12 Test preventing of converting special chars to html entities                               |  9 Add .travis.yml and status badges to README
 1