How does Monodeploy work? How do I get started?

[jeffrson]

I'm following the "Getting started" page, beginning with an empty work space, one git commit.

However, no matter what I do, it always shows "YN0000: No packages need to be updated."

Furthermore, according to the FAQ, it can be used in "no-registry mode" - honestly, what does it do then? I thought the whole point is in publishing.

Sorry - I'm confused.

[noahnu]

Monodeploy scans commit messages to determine the version strategy to use when deciding on the next version to publish.

If the version strategy is "minor", to get the next version, we apply "minor" to the current version. So if the current version is 1.2.3 then after applying minor we'll get 1.3.0.

By default, the current version is taken from npm. If you're familiar with semantic-release, they take the current version from git tags. When you use "no registry" mode, it will take the current version from the package.json rather than from npm. We do not have an option to read from git tags at the moment.

-- no registry will also avoid publishing to npm. What's the use case of this? It's mainly for cases where you want monodeploy to manage versions outside of npm. At our company we use monodeploy in a terraform modules repository. Monodeploy will publish git tags and create GitHub releases but won't interact with npm in that case. It's definitely not the core use case of monodeploy. Monodeploy was built for npm publishing.

As to why monodeploy is not detecting any changes. You can use log level 0 to get more info. I imagine you're not following a conventional commit syntax. You can specify a custom conventional commit config to fit your project. If there's no initial tag, monodeploy will only look at the most recent commit. This is essentially to "start it off".

Let me know how I can clarify this in the documentation. The architecture page provides some of this context, but I can see some value in a general "what is monodeploy" section.

[jeffrson]

Thank you for your explanation!

I had had a look into the "architecture" documentation, which is good, but it doesn't help me to find out why monodeploy didn't work for me, unfortunately.

I think it would be a helpful extension to the documentation, if "getting started" would go the way until the first publish. So far it describes how to create the workspace and call monodeploy. It might mention yarn set version stable (or berry). Furthermore, it could describe a very simple package (package.json and index.js) to demonstrate how to use git to commit such that monodeploy recognizes it.

Also the documentation could mention how it supposes the workspaces set up regarding git: monorepository with one repository for all packages and/or git submodules. lerna cannot cope with submodules, which is bad for us.

After it didn't work with our application monorepo I tried with a new test repo. I also had a look at "--log-level 0", but it didn't help (was only showing how git is called). I was wondering why monodeploy did'nt recognize my tags like v1.0.0 (from npm version). When reading the logs I decided to try something like @1.0.0. Now it apparently found the tag, but no change otherwise. But tags would be created by monodeploy anyway, wouldn't they. Well, maybe I'm a bit confused running these tests...

Yes, we are using conventional commits. And now I may be one step closer: our application repository only has "chore" commits lately, and my test repo had it too, coincidentally. Apparently this doesn't trigger publishing! Which could be helpful in the docs, I guess :-)

However, since submodules in our application usually have fix: and feat: commits, it seems like monodeploy doesn't look (yet?) at submodules, does it?

[noahnu]

I haven't tested with submodules, feel free to create a feature request. I can look at adding it to v3.

Regarding the tag v1.0.0, you're right that format is not looked at. This is because monodeploy by default publishes in the equivalent of lerna independent mode and so needs to track tags for packages independently. In group mode (fixed mode in lerna jargon) the format is group@v1.0.0. We have an open feature request around supporting v1.0.0 for group mode.

Regarding "chore", the built-in conventional config ignores it for publishing. It requires fix or feat. I might change that in v3 but also nothing prevents you from using a 3rd party conventional config. In fact I encourage it because the built-in config is missing changelog support (I think. But I'll double check and flesh it out in v3 anyway). At my company we always use monodeploy in conjunction with a conventional changelog config.