so I have a release c…
so… I have a release config at the root of my nx project - this is my common settings for all projects. Then each “releasable project” has it’s specific settings. Much of this is the same between projects except for the name.
Responses:
this and the couple messages before this talks about the setup
ok, I’ll look into it
Ok I managed to do this, but do you need to run semantic-release for every individual package?
add a release command to each of the project you want to be able to release in your angular.json (worspace.json)
it looks like this
"release": {
"builder": "@nrwl/workspace:run-commands",
"options": {
"commands": [
{
"command": "npx semantic-release --extends=./apps/member-portal-webui/release.config.js"
}
]
}
}
then you can use the nx command to run for all affected projects
nx affected --target=release
chat to me if you are running this on your CI server and run into issue where sem-rel says local is behind origin
remember release needs the built dist folder so that needs to run before the release command is run
I use a fan-out fan-in style CI workflow https://circleci.com/docs/2.0/workflows/#fan-outfan-in-workflow-example where I fan out to run all the lint/test/e2e tasks then fan-in to build and release. You do not necessarily have to fan-in during build if you figure out how to store your built artifacts so they can be retrieved during the release stage.
You could fanout and include your build –prod in your fanout then come together once all the pervious lint/test/build finishes fanout into a release process but you probably don’t need to because release is pretty light and you can just say nx affected --target=release --parallel
Ok, I’ll try this, currently I made different task for it
Only one additional issue I’m having
I’m running this on an azure devops pipeline. Everything seems to go well, but he doesn’t want to publish, he is telling that it only publishes on the master branch
I’m currently working on a feature branch and I added this also to the configuration
module.exports = {
branches: [
{ name: 'master' },
{ name: 'next', channel: 'next', prerelease: 'rc' },
{ name: 'feature/*', channel: 'alpha', prerelease: 'alpha' }
],
plugins: [
'@semantic-release/commit-analyzer',
'@semantic-release/release-notes-generator',
'@semantic-release/changelog',
'@semantic-release/git',
'@semantic-release/npm'
]
};
Im not sure if that work flow will work. Do you want to run a release on every push to your feature branch. I would generally use an alpha branch that I create a PR into from my feature, when that is approved / merged then run semantic release. I really don’t think you want to be generating a release on every feature branch that is created.
running locally with the no-ci flag it does :slightly_smiling_face:
I understand your concern, but it is for building internal libs and in those cases it is some times usefull, developers are eager to implement it once written :)
but I’ll try to use the normal flow first :slightly_smiling_face:
It’s not a use case I have tried although the documentation does seem to say it is supported.
it seems the changlog out put and the nx format are incompatible :slightly_smiling_face:
- what do you mean?
here is a snippet from my application release config.
module.exports = {
name: 'app1', // could come from angular.json
pkgRoot: 'dist/apps/app1', // should come from angular.json
tagFormat: 'app1-v${version}',
commitPaths: ['apps/lib1/*', 'libs/lib2/*'], // should come from dep-graph and angular.json
assets: ['apps/app1/README.md', 'apps/app1/CHANGELOG.md'],
plugins: [
'@semantic-release/commit-analyzer',
'@semantic-release/release-notes-generator',
[
'@semantic-release/changelog',
{
changelogFile: 'apps/app1/CHANGELOG.md',
},
],
[
'./release-scripts/artifactory',
{
dirToArchive: 'dist/apps/app1',
dirInArchive: 'home',
artifactoryPublish: true,
artifactoryUrl: '<http://private-repo/artifactory>',
artifactoryPath: '/private-repo/path/app1',
},
],
[
'@semantic-release/git',
{
message:
'chore(release): app1-v${nextRelease.version} [skip ci]\n\n${nextRelease.notes}',
},
],
],
};
then add .nxignore file that will prevent the changelog from messing with your affected reports
```# .nxignore works in the same way that .gitignore works. Files/Paths ignored in the .nxignore
will not impact the affected scripts
Updates to CHANGELOG.md should not be reported in affected
CHANGELOG.md```
it was the fact that it was changing the formatting when I ran nx format, but I added it to the prettierignore file to solve that. What you are mentioning is also very interesting :slightly_smiling_face:
Maybe a small disadvantage of the current way of working is that you get a commit for every package separately, but it is a small cost in favor of the benefits :slightly_smiling_face:
I decided that was a feature :-).
Basically it allows you to backout a single release if you had to. Although I would hate to actually have to do that
That is true! I managed to set this up so I’m happy, thanks for all the help.