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 7:49am
If you have another idea feel free to elaborate. This just came to my mind :)
  • reply
  • like
What I would like to note is, if and how the yarn.lock file is updated?
  • reply
  • like
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
Show more messages