stwe/MDCII

Proposal versioning

Opened this issue · 5 comments

I suggest using semantic versioning for this project.
There is a wide range of tools out there in this regard.

I suggest using tsemantic-release](https://github.com/semantic-release/semantic-release)
If you like I can setup a PR for that.
The only thing that you need to change is the commit message like Conventional Commits.
semantic-release is highly adaptable and can generate changelogs, builds, (pre)releases, all kinds of artifacts,...
it is integrated into GH actions easily.

What do you think?

stwe commented

Never used, I'll take a look...

stwe commented

Ok, I tried this new hipster stuff in another repo. The application somehow makes sense (it looks good), but the setup is an absolute horror. Is there a working example for Github somewhere? The following minimal setup works with limitations:

.github/workflows/release.yml

name: Release
on:
  push:
    branches: [ main ]

jobs:
  release:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18
      - run: npm ci
      - run: npx semantic-release
        env:
          GITHUB_TOKEN: ${{ secrets.GH_TOKEN }}

package.json

{
  "name": "my-pkg",
  "private": true,
  "release": {
    "branches": ["main"]
  },
  "repository": {
    "type": "git",
    "url": "https://github.com/stwe/blabla"
  }
}

And miraculously a v1.0.0 tag is created with "fix: semantic-release test".

Problem: the count should start with 0.1
Problem: I also had to create a package-lock.json in the repo because of the following error message:

npm ERR! The npm ci command can only install with an existing package-lock.json or
npm ERR! npm-shrinkwrap.json with lockfileVersion >= 1. Run an install with npm@5 or
npm ERR! later to generate a package-lock.json file, then try again.

Finally, I tried using the Changelog-Plugin. He can not find that, although this function would be important to me. Same as here: semantic-release/semantic-release#1898

Problem 1: the fact, that it starts with 1.0.0 is by design of semantic-release. You can always release pre-releases (see https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2 for the why).
tldr: it doesn't matter.

Problem 2: the package-lock.json comes from the npm ci step where you want a really well defined environment for your CI/CD. You don't want the build breaking just because some upstream library you are using in your CI chain changed. Thus the package-log.json is needed to ensure that the exactly defined environment will be installed.

stwe commented

I found a setup that works in other projects and which I will use here:

Run the following command in the project folder:

npm i semantic-release

Add to the created project.json:

{
  "name": "mdcii",
  "private": true,
  "release": {
    "branches": [
      "main"
    ]
  },
  //...
}

Install the plugins with:

npm i @semantic-release/changelog -D
npm i @semantic-release/git -D

Configure the plugins:

"plugins": [
  "@semantic-release/commit-analyzer",
  "@semantic-release/release-notes-generator",
  [
    "@semantic-release/changelog",
    {
      "changelogFile": "docs/CHANGELOG.md"
    }
  ],
  [
    "@semantic-release/git",
    {
      "assets": ["docs/CHANGELOG.md"]
    }
  ]
]

The node_modules folder needs to be in the .gitignore.

Create the release.yml file in .github/workflows/.

The content of the file looks like this:

name: Release
on:
  push:
    branches: [ main ]

jobs:
  release:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          cache: npm
          node-version: 18
      - run: npm ci
      - run: npx semantic-release

The only problem I have is setting up push access via token. There is the Workflow permissions menu, where you can set write permissions directly. Then it works.

@siredmar Any suggestions for improvement?

For semantic-release to work using github actions you need to create at personal access token with the following permissions:

image

I'd suggest using the Classic Token and set the expiration you want. Add the created token as secret in this repository and reference as used here #15 (comment)

I use this in all my repos and it works like a charm.