menu
Channels
Team

Commit Filtering and Other Monorepo Requests

October 23, 2019 at 4:45pm

Commit Filtering and Other Monorepo Requests

October 23, 2019 at 4:45pm (Edited 12 months ago)
Starting this thread here to pull it out of the issues and focus on a fork and get some input before starting. See https://github.com/semantic-release/semantic-release/issues/193 for additional context
Show previous messages

October 25, 2019 at 9:33am
- thanks Dan, I wasn't planning on putting semantic-release-flex under a scope but could be useful for some other things
  • reply
  • like
Just made some bad experience with publishing npm packages under a certain name, so I am always snugging the npm package name first before publishing anything useful :D
  • reply
  • like

October 27, 2019 at 6:19am
ok cool
  • reply
  • like
I don't have travis setup yet I will have to go through the settings but tests pass locally and I was able to release with the --no-ci flag
  • reply
  • like

October 28, 2019 at 3:27pm
I made a bit of an executive decision and change the package and repo name to semantic-release-plus I feel like it is more descriptive. I published a package that includes the commit filtering. It is a drop in replacement for semantic-release meaning you just uninstall semantic-release and install semantic-release-plus. NPM will complain about peer dependencies for the plugins. I am still deciding on how I want proceed with that. Here is all the relevant information:
Edited
  • reply
  • like
I am still considering updating the cmd name to semantic-release-plus rather than semantic-release. This would allow you to have both semantic-release and semantic-release-plus installed side by side
  • reply
  • like
For now you wont need to change any of your npm scripts/ci scripts they should still work but you can also add commitPaths to your release config and be able to filter commits.
Edited
  • reply
  • like

November 1, 2019 at 7:37pm
How do you process? :-)
  • reply
  • like

November 7, 2019 at 5:33am
Are you asking about progress?
  • reply
  • like
16.0.2 is out there and has the basic functionality for specifying the commit paths from the release config
  • reply
  • like
as well as you can monitor the releases like any semantic-release based project here https://github.com/semantic-release-plus/semantic-release/releases
  • reply
  • like

November 10, 2019 at 2:33am
Hi , I've been following this thread as I've also been looking for a solution to publishing several libraries from a monorepo.
I should point out I'm fairly new to semantic-release. I was using standard-version for previous non-monorepo libraries but started playing around with your fork of semantic-release to see if it could handle the task.
I've created a test repo here: https://github.com/codeandcats/mental-case and have been running standard-release-plus in dry mode with commit paths specified but it's not finding any commits, despite a recent feat commit that effected files in the path.
I'm not sure if it's something I've misconfigured (likely) or a problem with the feature. Would you mind taking a quick look please?
Edited
  • reply
  • like
Ah I see, it was a misunderstanding on my part. The commitPaths are relative to the current working directory that git log is ran in. So in my case, because I run semantic-release inside the subpackage, the commit path needs to be "./"
  • reply
  • like
Yes, I will work to clarify the documentation. I have been running semantic-release from the root of my mono-repo but using the -e flag to point to the project specific release config.
Edited
  • reply
  • like
Excellent. Thank you so much for working on this!
I think what says makes sense, that a complete solution for monorepos with libraries that depend on each other (what many monorepos may exist for) should update the dependency versions on the dependant packages in the monorepo and bump them in turn too, but this hopefully brings us a step closer to that goal.
  • reply
  • like
Oh btw, one other minor thing. When I tried to run semantic-release (plus) it actually errorred with:
env: node\r: No such file or directory
error Command failed with exit code 127.
It appears it's because I'm on a Mac and the bin file semantic-release was released with CRLF line endings (deployed from a Windows machine I'm guessing). If I edit that file and convert the line endings to LF it works as expected.
Edited
  • reply
  • like
On reflection, I think I take back what I said earlier re the "complete solution".
I'm now thinking that probably semantic-release shouldn't try to automatically update dependencies and bump library B in the monorepo when library A, that B depends on, gets bumped. I think this should be left to the maintainer since only they know if library B truly requires a patch, minor or major version bump when library A gets bumped.
Timing could also be an issue as someone might make a breaking change in library A and push that up to CI to release, but doesn't want library B to be automatically updated to use it and released as a major version as well. They might need to make further changes to library B before releasing as a major bump. The breaking changes in library A may introduce breaking changes in library B that causes bugs but aren't yet covered by tests which should be added and addressed before releasing a new major version of B.
Edited
  • reply
  • like
I got the travis setup thursday or friday but it was trying to build on node 8.3 if you see the semantic-release .travis.yml you will see it says 8.16. for some reason when I try to pull the fork source it does not detect this change. I will play with it more later today when I can find some time without the family.
  • reply
  • like
Ok, currently fighting with XO, builds pass on node 10 and 12 but fail on 8 with linting errors. Removed the node modules locally reinstalled ran xo --fix pushed and now 8 passes and 10 and 12 fail with a linting error. I have a feeling that Travis is caching a previous xo version.
Edited
  • reply
  • like
or anyone who can offer a hint. I have travis running but it is pulling in different versions of prettier (an xo dependency) between the different environments. Any thoughts on what might be the cause or what might be the fix?
  • reply
  • like
Show more messages