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 24, 2019 at 1:10pm
I love to see a a script that keeps our code updated, but can I suggest that we postpone that until we've implemented the changes?
like-fill
2
  • reply
  • like
currently there is none
  • reply
  • like
of course but all it basically is is search for file pattern in current implementation and update it.
  • reply
  • like

October 25, 2019 at 6:45am
semantic-release-flex it is I will setup the org and repo now
  • reply
  • like
I also check that there wasn't an existing package with this name :-)
  • reply
  • like
You can send me your email address so I can give you rights for the npm org :) created it just yet so nobody else can get it.
  • reply
  • like
  • reply
  • like
- 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
Show more messages