Dear @stevemao

We have an issue with Travis CI / Circle CI.
Always error when the command success.

We solve it with these args:

conventional-github-releaser -p angular -t $GH_TOKEN -r 0 2> /dev/null || true

Best regards.

Hello, is it normal that my releases lack proper formatting even though I'm correctly using Conventional Commit messages? See here please: https://github.com/coformatique/prisma-auth0-starter/releases

I'm using conventional-github-releaser -p angular as can be seen in my package.json file.

Thank you

This seems to fail because it tries to do a post instead of a patch if a tag already exists.

Looking through the source code, it seems that I cannot pass a host value to the node-github constructor to specify a GitHub Enterprise host.

Hello, I'm getting the following error when running conventional-github-releaser -p angular

GitHubError: Validation Failed (422)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] github-release: `conventional-github-releaser -p angular`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] github-release script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/Sammy/.npm/_logs/2017-11-20T16_07_15_550Z-debug.log

Here's the log file in question:

0 info it worked if it ends with ok
1 verbose cli [ '/usr/local/Cellar/node/8.7.0/bin/node',
1 verbose cli   '/usr/local/bin/npm',
1 verbose cli   'run',
1 verbose cli   'github-release' ]
2 info using [email protected]
3 info using [email protected]
4 verbose run-script [ 'pregithub-release', 'github-release', 'postgithub-release' ]
5 info lifecycle [email protected]~pregithub-release: [email protected]
6 info lifecycle [email protected]~github-release: [email protected]
7 verbose lifecycle [email protected]~github-release: unsafe-perm in lifecycle true
8 verbose lifecycle [email protected]~github-release: PATH: /usr/local/lib/node_modules/npm/bin/node-gyp-bin:/Users/Sammy/Projects/angular-project-starter/node_modules/.bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
9 verbose lifecycle [email protected]~github-release: CWD: /Users/Sammy/Projects/angular-project-starter
10 silly lifecycle [email protected]~github-release: Args: [ '-c', 'conventional-github-releaser -p angular' ]
11 silly lifecycle [email protected]~github-release: Returned: code: 1  signal: null
12 info lifecycle [email protected]~github-release: Failed to exec github-release script
13 verbose stack Error: [email protected] github-release: `conventional-github-releaser -p angular`
13 verbose stack Exit status 1
13 verbose stack     at EventEmitter.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:280:16)
13 verbose stack     at emitTwo (events.js:125:13)
13 verbose stack     at EventEmitter.emit (events.js:213:7)
13 verbose stack     at ChildProcess.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack     at emitTwo (events.js:125:13)
13 verbose stack     at ChildProcess.emit (events.js:213:7)
13 verbose stack     at maybeClose (internal/child_process.js:927:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
14 verbose pkgid [email protected]
15 verbose cwd /Users/Sammy/Projects/angular-project-starter
16 verbose Darwin 16.7.0
17 verbose argv "/usr/local/Cellar/node/8.7.0/bin/node" "/usr/local/bin/npm" "run" "github-release"
18 verbose node v8.7.0
19 verbose npm  v5.5.1
20 error code ELIFECYCLE
21 error errno 1
22 error [email protected] github-release: `conventional-github-releaser -p angular`
22 error Exit status 1
23 error Failed at the [email protected] github-release script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]

Re-posting the following enhancement suggestion from the previous GitLab project for conventional-gitlab-releaser:

Alexander Kachkaev @kachkaev:

At the moment tagname is hardcoded to have a format of D.D.D. It would be nice if users could also release vD.D.D (e.g. like GitLab does this itself)

Alexander Kachkaev @kachkaev:

This could be probably solved either in a form of a boolean flag or an optional transform function. What would be also nice is to have a transform function for the message field, which currently defaults to Release x.x.x. Someone may want to see smth like Release x.x.x (YYYY-MM-DD), for instance.

Me:

@kachkaev I believe the value passed to tag_name is nothing more than the tag created by the following line. Therefore, perhaps we can update semantic-release-gitlab to prepend a v, and allow that to propagate to semantic-release-gitlab-releaser and semantic-gitlab-notifier? Thoughts on that idea?

As for your second idea, would you mind breaking that out into a separate issue? As for the transform function idea, I like the idea. I think it's fantastic. The only issue we'll need to keep in mind is that the arguments we pass to conventional-gitlab-releaser need to match conventional-github-releaser. We plan on merging the two projects together in the future.

Alexander Kachkaev @kachkaev:

Thanks for your reply @hutson!

Looks like that line is not the only one that needs changing. In index.js of conventional-gitlab-releaser the remote tag on GitLab is derived from the semver again. I'm using this package separately from semantic-release-gitlab and still can't get v in the version.

Possible solution:

// before
conventionalGitlabReleaser(AUTH, {
  preset: 'angular'
}, callback);

// after
conventionalGitlabReleaser(AUTH, {
  preset: 'angular',
  vInTag: true
}, callback);

// ...
gitlab.projects.repository.addTag({
            id: context.owner + '/' + context.repository,
            // 'tag_name': version, // <-- before
            'tag_name': (changelogOpts.vInVersion ? 'v' : '') + version, // <-- after
            ref: chunk.keyCommit.hash,
            message: 'Release ' + version,
            'release_description': chunk.log
          }, function(response) {
// ...

How about this?

Perhaps, something like tagPrefix: 'v' could be an alternative to a boolean flag, but I can't remember any repos that would use any other convention for semantic tags rather than D.D.D or vD.D.D.

Alexander Kachkaev @kachkaev:

Re. release transform function: https://gitlab.com/hyper-expanse/conventional-gitlab-releaser/issues/5

Me:

@kachkaev the boolean proposal for conventional-gitlab-releaser looks fine with me. Please feel free to submit a pull request to add that option.

Alexander Kachkaev @kachkaev:

I'm not sure I'll find time for this @hutson. Feel free to reuse my code in a new PR! I might be back when I find a need to use your library again, it really helped me last year 😉

https://github.com/conventional-changelog/git-raw-commits/releases/tag/v1.1.1
there is a whitespace missing signs(005b559)
https://github.com/conventional-changelog/git-raw-commits/blob/master/CHANGELOG.md
But it's correct with conventional-changelog

For some reason I started getting this error when publishing to GitHub, although it seems as though the actual release works fine:

> [email protected] github-release /Users/fergusmcdowall/node/search-index-adder
> conventional-github-releaser -p angular

[ { url: 'https://api.github.com/repos/fergiemcdowall/search-index-adder/releases/6932093',
    assets_url: 'https://api.github.com/repos/fergiemcdowall/search-index-adder/releases/6932093/assets',
    upload_url: 'https://uploads.github.com/repos/fergiemcdowall/search-index-adder/releases/6932093/assets{?name,label}',
    html_url: 'https://github.com/fergiemcdowall/search-index-adder/releases/tag/v0.3.6',
    id: 6932093,
    tag_name: 'v0.3.6',
    target_commitish: 'master',
    name: 'v0.3.6',
    draft: false,
    author:
     { login: 'fergiemcdowall',
       id: 1122333,
       avatar_url: 'https://avatars2.githubusercontent.com/u/1122333?v=3',
       gravatar_id: '',
       url: 'https://api.github.com/users/fergiemcdowall',
       html_url: 'https://github.com/fergiemcdowall',
       followers_url: 'https://api.github.com/users/fergiemcdowall/followers',
       following_url: 'https://api.github.com/users/fergiemcdowall/following{/other_user}',
       gists_url: 'https://api.github.com/users/fergiemcdowall/gists{/gist_id}',
       starred_url: 'https://api.github.com/users/fergiemcdowall/starred{/owner}{/repo}',
       subscriptions_url: 'https://api.github.com/users/fergiemcdowall/subscriptions',
       organizations_url: 'https://api.github.com/users/fergiemcdowall/orgs',
       repos_url: 'https://api.github.com/users/fergiemcdowall/repos',
       events_url: 'https://api.github.com/users/fergiemcdowall/events{/privacy}',
       received_events_url: 'https://api.github.com/users/fergiemcdowall/received_events',
       type: 'User',
       site_admin: false },
    prerelease: false,
    created_at: '2017-07-03T05:13:19Z',
    published_at: '2017-07-05T05:56:41Z',
    assets: [],
    tarball_url: 'https://api.github.com/repos/fergiemcdowall/search-index-adder/tarball/v0.3.6',
    zipball_url: 'https://api.github.com/repos/fergiemcdowall/search-index-adder/zipball/v0.3.6',
    body: '### Features\n\n* **indexing:** can now do appendOnly ([be5167e](https://github.com/fergiemcdowall/search-index-adder/commit/be5167e))',
    meta:
     { 'x-ratelimit-limit': '5000',
       'x-ratelimit-remaining': '4997',
       'x-ratelimit-reset': '1499234292',
       'x-oauth-scopes': 'repo',
       location: 'https://api.github.com/repos/fergiemcdowall/search-index-adder/releases/6932093',
       etag: '"48c9e37b6d98af87149133b3ae640fe5"',
       status: '201 Created' } } ]

npm ERR! Darwin 16.6.0
npm ERR! argv "/Users/fergusmcdowall/.nvm/versions/node/v7.9.0/bin/node" "/Users/fergusmcdowall/.nvm/versions/node/v7.9.0/bin/npm" "run" "github-release"
npm ERR! node v7.9.0
npm ERR! npm  v4.2.0
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] github-release: `conventional-github-releaser -p angular`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] github-release script 'conventional-github-releaser -p angular'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the search-index-adder package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     conventional-github-releaser -p angular
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs search-index-adder
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls search-index-adder
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/fergusmcdowall/.npm/_logs/2017-07-05T05_56_41_987Z-debug.log

Hey all,

Great tool! 🚀 I really appreciate and love all of the hard work you've all put into this project. I've run into an issue that I can't seem to figure out and wondering if you can hopefully shine some light on it.

I'm using the latest version of Github Releaser and npm 10.15.1. I'm running the following commands from our Jenkins server, adding releases to our GitHub Enterprise server (v2.15.x).

./node_modules/.bin/conventional-github-releaser -t **** -u https://github.<ghe_domain>.com/api/v3 -p angular

The command works and creates the release on GitHub and works but the output appears to list out the following:

ParseError: Unexpected end of JSON input in "https://github.<ghe_domain>.com/api/v3/repos/platform/build-process-test/releases": 
{"url":"https://github.<ghe_domain>.com/api/v3/repos/platform/build-process-test/r...

I want to use the changelog generated by standard-version because it look much nicer. Is it possible somehow to pass custom content? Maybe a new flag where I can pass a changelog's path to be used?

I have a regex to fetch content from changelogs.

Something like this:

const start = changelog.match(new RegExp(`^#.*${escapeRegExp(version)}.*`, 'gm'))
changelog += '\n#0.0.0' // eslint-disable-line
const match = Array.from(
    changelog.matchAll(new RegExp(`${escapeRegExp(start)}([\\s\\S]+?)(^#{1,4}.*\\d+\\.\\d+\\.\\d+)`, 'gm'))
)[0]

This will search for headers with a specified semver version included until another header including semver version and use the content between this two.

I can understand if there's no intention to implement such solution, however custom content would be nice and I couldn't find any docs related to achieve such.

In conventional-github-releaser versions below 3.1.2 my gulp release script works correctly:

function createRelease(done) {
  githubReleaser(
    {
      type: 'oauth',
      token: process.env.CONVENTIONAL_GITHUB_RELEASER_TOKEN
    },
    done
  )
}

With version 3.1.2 though I get:

[18:58:56] Starting 'createRelease'...
[18:58:56] 'createRelease' errored after 255 ms
[18:58:56] RequestError: getaddrinfo ENOTFOUND undefinedrepos undefinedrepos:443
    at ClientRequest.req.once.err (/Users/alec/projects/my-site/node_modules/got/index.js:182:22)
    at Object.onceWrapper (events.js:272:13)
    at ClientRequest.emit (events.js:180:13)
    at ClientRequest.emit (domain.js:421:20)
    at TLSSocket.socketErrorListener (_http_client.js:395:9)
    at TLSSocket.emit (events.js:180:13)
    at TLSSocket.emit (domain.js:421:20)
    at emitErrorNT (internal/streams/destroy.js:64:8)
    at process._tickCallback (internal/process/next_tick.js:114:19)
[18:58:56] 'release' errored after 5.73 s

Re-posting the following enhancement suggestion from the previous GitLab project for conventional-gitlab-releaser:

Posted by Marco Massarotto @brokenmass:

This project, at the moment, publish the change log by CREATING a new git tag (https://docs.gitlab.com/ce/api/tags.html#create-a-new-tag) with associated description.
This means that the tag has to exist locally but NOT on the remote gitlab otherwise the whole process fails.
It also means that's impossible to fully regenerate your past releases unless you remove the tags remotely (and not only the associated release notes), BUT not locally.

To clean this up and to make it more consistent with conventional-github-releaser I would like to modify this approach and have it create a release instead (https://docs.gitlab.com/ce/api/tags.html#create-a-new-release)
This change would be a BREAKING CHANGE, as it will require the tag to exist on both local and remote (requires git push --tags / --follow-tags before running conventional-gitlab-releaser, unless we first check if the tag exists and based on the results creates a tag or a release to make the change backward compatible.

Any thoughts ?

Me:

I'm sorry @brokenmass for missing this issue. I haven't been receiving GitLab notification e-mails, and I haven't put in the proper effort to address the issue.

To clean this up and to make it more consistent with conventional-github-releaser

Having looked into the differences between conventional-github-releaser and conventional-gitlab-releaser a little more, I see what you mean by conventional-gitlab-releaser being inconsistent in how it creates tags on GitLab.

requires git push --tags / --follow-tags

I'd like to avoid pushing the tags to GitLab. Using gl-got, and the GitLab API makes it a little easier to reason about expectations and to write unit tests.

unless we first check if the tag exists and based on the results creates a tag or a release

So creating a release on GitHub will create a tag if it doesn't exist, and then apply the release notes to the tag. If the tag already existed, it won't fail. It just applies the release notes to that tag.

However, conventional-gitlab-releaser does not expect the tag to exist, and it will fail if it does.

So instead, how about first trying to create an annotated tag with release notes, and if that returns a 405, assuming the tag exists, and then try to create a new release, and if that returns a 409, because the release already exists, try to update an existing release?

The latter part is not entirely consistent with conventional-github-releaser either, but I think updating the release notes is still preferred over failing. At least in my opinion.

@brokenmass what are your thoughts, and does my suggestion align with your suggestion/needs mentioned above?

Posted by Marco Massarotto @brokenmass:

However, conventional-gitlab-releaser does not expect the tag to exist, and it will fail if it does.

It doesn't expect it to exist on the remote, but it require it to exist locally. That means that the remote tag creation will be a bit of dark magic if done by conventional-gitlab-releaser, which role is to just create release notes.
But sure that seem like a feasible solution.

try to update an existing release?

Not really convinced by this idea. I would expect it to fail unless some sort of force flag is passed as parameter (--force-update)

Will send you a PR soon.

Posted by Marco Massarotto @brokenmass:

well @hutson ...
it ended becoming a major rewrite of the application, more focused on a cleaner promise like approach but still providing the ability to stream the results as they are generated.
unit tests and decent commits messages on their way
https://gitlab.com/hyper-expanse/conventional-gitlab-releaser/merge_requests/28

OS: Windows
Node: v5.5.0
npm: v3.7.3
conventional-github-releaser: v1.1.0

I tried to remove and install all packages, update node, but the issue wasn't fixed. Then I installed github-remove-all-releases, removed all releases and tried to regenerate releases again with option releaseCount: 0. But nothing happened.

My gulp task:

gulp.task('github-release', function(done) {
  conventionalGithubReleaser({
    type: 'oauth',
    token: process.env.CONVENTIONAL_GITHUB_RELEASER_TOKEN
  }, {
    preset: 'angular'
  }, done);
});

Token is valid.

It worked like a charm before update.

For the past month I've been looking into an issue that was filed against semantic-release-gitlab-notifier by @bahmutov - https://gitlab.com/hutson/semantic-release-gitlab-notifier/issues/1

@bahmutov describes a workflow where semantic-release-gitlab (the tool he uses for generating new releases for a GitLab-based project) is invoked only when a new tag is created on the master branch of his repository. His goal is to collect several commits into the master branch, and then, when he's ready to publish a new version of his package to the npm registry, he tags the master branch with a tag beginning with the word release.

You can see the tag pattern used to invoke the deploy stage of his CI pipeline here.

The semantic-release-gitlab tool correctly generates a new version based on the commits since the last semantically valid tag, correctly ignoring the release tag created manually by @bahmutov.

However, when semantic-release-gitlab invokes conventional-gitlab-releaser (my fork of conventional-github-releaser) to generate release notes, it fails.

It comes down to the call to conventionalChangelog, from within conventional-gitlab-releaser, which fails to return a changelog. Therefore, there's nothing to post to GitLab.

Based on my testing so far, it seems the transform function is matching against the manually created release tag, using the manually created release tag as the version of the latest commit, and that is causing conventional-changelog-writer to fail to generate a changelog.

If I modify the transform function for conventional-gitlab-releaser to match only the semantically valid version tag created by semantic-release-gitlab the changelog is generated correctly, and a release note is posted to GitLab.

I have a pending merge request against conventional-gitlab-releaser that demonstrates the required change - https://gitlab.com/hutson/conventional-gitlab-releaser/merge_requests/1/diffs

I haven't accepted it yet because I'm not quite sure what the purpose of the transform function is, or whether my change is the best approach.

I wanted to get your input before proceeding.

Hi,

having a problem with this cli command.

When there are releases that can be generated, everything is fine. but if none are returned from the module, the cli is exiting with exit code 1 in here. There need to be a check for an empty array that exits with code 0.

Gonna open a PR for that in a few.

as an example: https://github.com/stevemao/conventional-github-releaser/releases/tag/v0.1.0

Or if they are shown, they should have their own section.

It's not possible to use the releaser tool unless you tag exactly with semver tags because it consumes the git-semver-tags package directly.

This is the line:
https://github.com/conventional-changelog/releaser-tools/blob/master/packages/conventional-github-releaser/src/index.js#L50

For better or worse, I have a website project that doesn't use semver tags, but an incremental counter tag, so v1, v2, v3, v4, v18273 and so forth; and alas these are not picked up by the semver tags so I can't get nice changelogs released 😢

Even providing from/to GIT SHAs doesn't work because the git tags check is still performed regardless.

I suggest:

• Skip tag loading when a from and to value is provided.
• Allow passing a function that can be used for returning tag data to replace git-semver-tags

When I use the -n flag with the angular config file my release messages it doesn't work.
My commits are not format

I don't use the -p flag because I want to custom the angular file.

and i got a template dir with angular templates

I keep getting Error: No tags found when running conventional-github-releaser -p angular

I can echo my env var $CONVENTIONAL_GITHUB_RELEASER_TOKEN.

I created a test repo to test things out:

± |master ✓| → git ls-remote
From [email protected]:psyrendust/release-test.git
6a34dcd83951213a96f51736694cbcfa7054fa2f    HEAD
fab70e59230304040bf9375971a6cfb44ff004f7    refs/heads/develop
6a34dcd83951213a96f51736694cbcfa7054fa2f    refs/heads/master
b0e68f75230083b337a9506b43376070abf047d0    refs/tags/v0.0.1
fa59d84ed08fae601b33fc3f3c259c8a50489480    refs/tags/v0.0.1^{}
4ae42acf35833f63e63e70925b8af9dd2f17e687    refs/tags/v0.0.2
6a34dcd83951213a96f51736694cbcfa7054fa2f    refs/tags/v0.0.2^{}

I have a few tags, a develop and master branch. I've checked the access permissions of my personal access token and everything is fine there.

I just globally installed version 1.1.1 of git-semver-tags and ran the command in my test repo and it doesn't output any tags.

I'm using the following shell script to automate my release process:

#!/usr/bin/env bash
# define branches
develop="develop"
master="master"

gitCurrBranch() {
  ref=$(command git symbolic-ref HEAD 2> /dev/null) || \
  ref=$(command git rev-parse --short HEAD 2> /dev/null) || return
  echo "${ref#refs/heads/}"
}

publish() {
  # start with develop branch and make sure that master and develop
  # have both been rebased against each other
  currBranch=`gitCurrBranch` &&
  [ "$currBranch" != $master ] && git checkout $master;
  git rebase $develop &&

  # run tests
  # travis status --no-interactive &&
  trash node_modules &>/dev/null;
  npm install &&
  npm run test &&

  # bump version and build changelog
  cp package.json _package.json &&
  preset=`conventional-commits-detector` &&
  echo $preset &&
  bump=`conventional-recommended-bump -p angular` &&
  echo ${1:-$bump} &&
  npm --no-git-tag-version version ${1:-$bump} &>/dev/null &&
  conventional-changelog -i CHANGELOG.md -w -p ${2:-$preset} &&
  git add CHANGELOG.md &&
  version=`cat package.json | json version` &&

  # commit changes
  git commit -m"docs(CHANGELOG): $version" &&
  mv -f _package.json package.json &&
  npm version ${1:-$bump} -m "chore(release): %s" &&

  # push changes to remote
  git push origin $master &&
  git push origin $develop &&
  git push --tags

  # Update github releases
  conventional-github-releaser -p ${2:-$preset}

  # rebase master onto develop
  git checkout $develop &&
  git rebase $master &&
  git push origin $develop
}

conventional-changelog have supported lerna-style package.

• make conventional-changelog play nicely with lerna · Issue #168 · conventional-changelog/conventional-changelog

Do conventional-github-releaser have any chance to support lerna?

conventional-github-releaser -p angular --lerna pkg-name
# Update pkg-name@version release note

Modify conventional-gitlab-releaser to assign the changelog/release notes to the message property so that the release notes are used as the tag annotation.

There's some interest within the GitLab community to store the changelog/release notes in the tag annotation - https://gitlab.com/gitlab-org/gitlab-ce/issues/20587

Code to change -

Hi there,

when upgrading to meow ^4.0.0 on commit 8f120c9, the usage of the aliases on conventional-github-releaseer got broken. We have to use --token instead of -t, or --config instead of -n.

The release notes of https://github.com/sindresorhus/meow/releases warn on the way minimist options need to be passed for version ^4.0.0.

I have created #62 that solves the issue. On top of it, the second commit adds the types of the flags as recommended in meow's README. I haven't created test because src/cli.js is explicitly excluded from them.

By the way @hbetts, out of interest, why is that you mention using yarn in the contributing if you are using package-lock.json? I have used npm because of the existence of package-lock.json. The links to the GitHub repo for issues and PRs read GitLab, as another small thing to correct in the CONTRIBUTING.md

The tests initially did not run, because I'm in GMT+2 and the line chunk.committerDate = dateFormat(chunk.committerDate, 'yyyy-mm-dd', true) in the transform.js, for both GitHub and GitLab, the 8th of June at 00:00 gets transformed to 7th June at 22:00 I guess?

Please let me know any feedback.

After updating to 3.1.1 I receive the following error when attempting to run the releaser:

RequestError: getaddrinfo ENOTFOUND api.github.comrepos api.github.comrepos:443

I assumed it was a string interpolation error missing the / at the end of the base URL. So I updated CONVENTIONAL_GITHUB_URL to be https://api.github.com/.

After updating the env var, I receive a GithubError:

GitHubError: Validation Failed (422)

However it looks like the release does actually POST to Github.

This project was working fine, then we ran into issue #58 . This prompted us to try upgrading to the latest version which resulted in what I reported above.

Thanks!

I apologize for spamming #14

So I believe my issue was a result of the unit tests operating under the assumption that I have access to a repository called stevemaotest/conventional-github-releaser-test.

It's actually impossible to verify any changes I make locally.

Therefore I wanted to propose extending the testing suite with offline unit and integration tests.

For unit testing we could use something like proxyquire, and for integration tests we could use nock.

• create scss folder
• create _variables.scss file and move all scss var into this file
• import new file in main file
• adopt webpack config for new structure

In new version of the conventional-changelog there is a different approach to passing a preset option, preset option has to be now a {name: string} instead of string.

I have created PR #166 with updated library reference and appropriate change in code to accomodate that without introducing a breaking change.

I can't find either changelog or release notes for major version bump.

Should checked out submodules be included in the release?

TEST_CONVENTIONAL_GITHUB_RELEASER_TOKEN is hashed by travis.

Seeing a random error on our deployments, will continue to dig deeper.

					throw new TypeError(`Expected "${key}" default value to be of type "${expectedType}", got ${prettyPrint(defaultType)}`);
					^

TypeError: Expected "verbose" default value to be of type "boolean", got "string"
    at /usr/local/lib/node_modules/conventional-github-releaser/node_modules/minimist-options/index.js:101:12
    at Array.forEach (<anonymous>)
    at buildOptions (/usr/local/lib/node_modules/conventional-github-releaser/node_modules/minimist-options/index.js:64:23)
    at meow (/usr/local/lib/node_modules/conventional-github-releaser/node_modules/meow/index.js:136:18)
    at Object.<anonymous> (/usr/local/lib/node_modules/conventional-github-releaser/src/cli.js:9:13)
    at Module._compile (internal/modules/cjs/loader.js:1138:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1158:10)
    at Module.load (internal/modules/cjs/loader.js:986:32)
    at Function.Module._load (internal/modules/cjs/loader.js:879:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
##[error]Process completed with exit code 1.```

In package.json, I can read it:

"engines": {
  "node": "^6.9.0 || ^4.2.0",
  "npm": "^4.0.0 || ^3.0.0 || ^2.1.9"
}

I am using node v8.0.0, I have the following error:

error [email protected]: The engine "node" is incompatible with this module. Expected version "^6.9.0 || ^4.2.0".

Can you remove engines section from package.json?

It looks much prettier in the changelog. The release notes only have a mixed list of commit messages without any additional formatting.

See below for output when trying to run from fresh install.

May be related to #184.

$ npm install -g conventional-github-releaser
...
+ [email protected]
...
$ conventional-github-releaser       
/usr/local/lib/node_modules/conventional-github-releaser/node_modules/minimist-options/index.js:101
                                        throw new TypeError(`Expected "${key}" default value to be of type "${expectedType}", got ${prettyPrint(defaultType)}`);
                                        ^

TypeError: Expected "token" default value to be of type "string", got "undefined"
    at /usr/local/lib/node_modules/conventional-github-releaser/node_modules/minimist-options/index.js:101:12
    at Array.forEach (<anonymous>)
    at buildOptions (/usr/local/lib/node_modules/conventional-github-releaser/node_modules/minimist-options/index.js:64:23)
    at meow (/usr/local/lib/node_modules/conventional-github-releaser/node_modules/meow/index.js:125:18)
    at Object.<anonymous> (/usr/local/lib/node_modules/conventional-github-releaser/src/cli.js:9:13)
    at Module._compile (internal/modules/cjs/loader.js:1138:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1158:10)
    at Module.load (internal/modules/cjs/loader.js:986:32)
    at Function.Module._load (internal/modules/cjs/loader.js:879:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)

Please show me a way to include a tag on a merge commit. How do I do that with gitRawCommit.opts?

Hi,

Thanks for this great tool!

The last two releases (v1.1.4 and v1.1.5) give me this error (works fine with v1.1.3) when running a gulp task:

Error: Cannot find module './lib/transform'
    at Function.Module._resolveFilename (module.js:470:15)
    at Function.Module._load (module.js:418:25)
    at Module.require (module.js:498:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (<PATH_TO_MY_PROJECT>\node_modules\conventional-github-releaser\index.js:10:17)
    at Module._compile (module.js:571:32)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)

Any idea?

dig out all previous commits and add a test for each.

Re-posting the following enhancement suggestion from the previous GitLab project for conventional-gitlab-releaser:

Alexander Kachkaev @kachkaev:

It would be nice if there was some transform function for the message field, which currently defaults to Release x.x.x. Someone may want to see smth like Release x.x.x (YYYY-MM-DD), for instance.

Me:

I think this is a great idea! 😄

Perhaps adding an option to changelogOpts for, as you noted, a transform function, that can be used on line 82.

Would someone be willing to submit a merge request for this enhancement?

I've just stumbled upon conventional-github-releaser, having used standard-version for awhile and searching for a way to customize how the CHANGELOG.md is generated. It appears that the templating system may be provided by the underlying conventional-changelog tool, but I can't seem to find any documentation at any level of these tools which actually walks you through how to create a custom template. The help output says:

    -c, --context             A filepath of a javascript that is used to define template variables

... but I can't find any documentation as to what the contents of this file is supposed to look like. Are there some existing docs that I'm missing?

Thanks.

It seems like when working with git-flow and the way git flow tags the commits, the release doesn't seems to work.

Tagging manually works fine!

It's there a different the way git-flow tags and manual tag?

Hi,

I was recently configuring conventional-github-releaser and it appeared to working, but no release messages were being written to github (but the tags were being created). After a while I realized this was because the wrong repository URL was set in package.json (Another repo i have access to was where the release messages were being written to).

If the repository URL configured in package.json is not the same as the git working directory, should/could a warning be displayed or error be thrown? Although this was a silly error on my behalf, such a simple check could save other users time if they were to make the same mistake.

Adam.

Any hints as to why this is failing?

env DEBUG="conventional-github-releaser,octokit:rest*" conventional-github-releaser -p angular -r 0
  conventional-github-releaser posting { endpoint: 'https://api.github.com/', body: { body: '\n\n\n', draft: false, name: '0.0.1', prerelease: false, tag_name: '0.0.1', target_commitish: undefined } } to the following URL - repos/xxx/xyzzy/releases +0ms
GitHubError: Validation Failed (422)

This started to happen with the recent updates. Until now this was working fine:

// package.json
{
    "scripts": {
        "release": "conventional-github-releaser -t"
    }
}

npm run release -- MY_TOKEN

But I started to get the following error:

C:\...es\conventional-github-releaser\node_modules\meow\node_modules\minimist-options\index.js:101
                                        throw new TypeError(`Expected "${key}" default value to be of type "${expectedType}", got ${prettyPrint(defaultType)}`);
                                        ^

TypeError: Expected "token" default value to be of type "string", got "undefined"
    at C:\node_modules\conventional-github-releaser\node_modules\meow\node_modules\minimist-options\index.js:101:12
    at Array.forEach (<anonymous>)
    at buildOptions (C:\node_modules\conventional-github-releaser\node_modules\meow\node_modules\minimist-options\index.js:64:23)
    at meow (C:\node_modules\conventional-github-releaser\node_modules\meow\index.js:136:18)
    at Object.<anonymous> (C:\node_modules\conventional-github-releaser\src\cli.js:9:13)
    at Module._compile (internal/modules/cjs/loader.js:1200:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1220:10)
    at Module.load (internal/modules/cjs/loader.js:1049:32)
    at Function.Module._load (internal/modules/cjs/loader.js:937:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)

Sometimes when I use this tool I have the need to adjust the changelog manually to fix some things or add things not captured in the git log. I usually use conventional-changelog to update a CHANGELOG.md file and afterward this tool to additionally update the releases page. Now currently I have to make those edits twice, once to CHANGELOG.md and then again on the release page because the github-releaser does not check that file.

The best solution I have come up so far with is an option where it uses the infile as a basis of the content of the release on github instead of the raw git log. What do you think?

I tried in different repo, always get this error.

conventional-github-releaser
GitHubError: Not Found (404)

I'm using a v prefix for my version tags (v1.0.0), and
I'm using conventional-github-releaser from the CLI.

After tagging the repo, I run the following commands:
git push --follow-tags origin master
conventional-github-releaser -t $GITHUB_TOKEN -p angular

If my tag is v1.0.1, instead of creating the release on that tag, conventional-github-releaser is adding a new tag to my remote repo, without the prefix: 1.0.1. It then attaches the release to that tag, instead of the one that I actually pushed. It doesn't delete the prefix tag, it just fails to use it.

This behavior started sometime between 1.1.3 and 1.1.9

What scopes are needed for the token? this should be included in the docs probably.