favoloso / conventional-changelog-emoji

Conventional Changelog with Emojis support πŸŽ‰
MIT License
40 stars 8 forks source link

semantic-release #20

Open Ponjimon opened 4 years ago

Ponjimon commented 4 years ago

Ref https://github.com/favoloso/conventional-changelog-emoji/issues/4#issuecomment-606678898

Will this work with https://github.com/semantic-release/semantic-release? because I'm trying to make it work and apparently it uses it (config option), but nothing happens. It doesn't detect any changes.

This is the config:

{
"release": {
    "config": "@favoloso/conventional-changelog-emoji",
    "branches": [
      "master"
    ],
    "plugins": [
      "@semantic-release/commit-analyzer",
      "@semantic-release/release-notes-generator",
      [
        "nx-semantic-release",
        {
          "targets": [
            "build-image"
          ],
          "extraArgs": [
            "--service=simon",
            "--stage=dev",
            "--region=us-east-1"
          ]
        }
      ]
    ]
  }
}
leonardfactory commented 4 years ago

usually preset name should be specified as @org/<omit conventional-changelog->name, as specified in conventional-changelog docs here. Can you try with @favoloso/emoji and let me know if it does work this way?

PS: Furthermore this is preset way, not config, ~~not sure if semantic-release supports it. ~~However you could give it a try with preset: "@favoloso/emoji" instead of config: ..

Edit: The official docs talk about the preset, so preset: "@favoloso/emoji" should be ok :+1:

Ponjimon commented 4 years ago

It tried it like that and, unfortunately, it errors as it tries to load.

Error: Cannot find module 'conventional-changelog-@favoloso/emoji' 😞

leonardfactory commented 4 years ago

Which one? Config or preset?

Ponjimon commented 4 years ago

Preset

leonardfactory commented 4 years ago

Yep after looking at the source code it seems like @favoloso/emoji pattern is not recognized, so we should stick to config. You are saying that it does not detects any changes, could you post the output of git log $(git describe --tags --abbrev=0)..HEAD --oneline ?

Ponjimon commented 4 years ago

fatal: No names found, cannot describe anything. πŸ€”

The last commit message is 🚨 test

leonardfactory commented 4 years ago

We've got some issues with breaking changes in commit messages, for now suggested use is BREAKING CHANGE: .. or 🚨: in commit description (#9) . Have you get any other commit?

PS: It should work, but since breaking change is a bit different from other commits I'd like to know if the problem lies somewhere else

Ponjimon commented 4 years ago

I changed the commit message to ✨ test but it also doesn't do anything.

[7:13:14 PM] [semantic-release] β€Ί βœ”  Completed step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[7:13:14 PM] [semantic-release] β€Ί β„Ή  There are no relevant changes, so no new version is released.
Ponjimon commented 4 years ago

Oddly enough, recommendedBumpOpts is not used anywhere and that's what's responsible for deciding, isn't it? Am I missing a required semantic-release plugin or something...?

leonardfactory commented 4 years ago

Really odd. I don't grasp why it is like that, but semantic-release is not using the recommendedBump method available with conventional changelogs, but instead is using customΒ releaseRules that completely by pass the recommendedBump method, i.e.:

["@semantic-release/commit-analyzer", {
      "preset": "angular",
      "releaseRules": [
        {"type": "docs", "scope":"README", "release": "patch"},
        {"type": "refactor", "release": "patch"},
        {"type": "style", "release": "patch"}
      ],
      "parserOpts": {
        "noteKeywords": ["BREAKING CHANGE", "BREAKING CHANGES"]
      }
    }]

What you can do here is to define manually this kind of rules, like:

releaseRules: [
  {  emoji: "✨", release: "minor" }
]

It doesn't seem like a good method to me, especially since recommendedBump is definitely better here (recognizes initial development version). I didn't dig into the source, but well here we go.

Can you try with this sample releaseRules ?

Ponjimon commented 4 years ago

It indeed does work with that setting. Very odd.

leonardfactory commented 4 years ago

Unfortunately, there is no built-in solution. You can try using this releaseRules i pulled out from this plugin configuration, so behaviour should be similar, even if I'm not sure it will handle v0.x

"releaseRules": [
  {"emoji":"🚨","release":"major"},
  {"emoji":"✨","release":"minor"},
  {"emoji":"πŸ”’","release":"patch"},
  {"emoji":"πŸ› ","release":"patch"},
  {"emoji":"⚑️","release":"patch"},
  {"emoji":"πŸ›","release":"patch"},
  {"emoji":"πŸ“š","release":"patch"},
  {"emoji":"πŸ—","release":"patch"},
  {"emoji":"🎨","release":"patch"},
  {"emoji":"♻️","release":"patch"},
  {"emoji":"🚦","release":"patch"},
  {"emoji":"πŸ“¦","release":"patch"},
  {"emoji":"πŸ”–","release":"patch"},
  {"emoji":"🚧","release":"patch"}
]