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?
Never used, I'll take a look...
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.
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:
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.