This is a very simple project structure which serves as an example of how kmono is intended to be setup and used.
This is the overall structure of the project:
.
├── packages
│ ├── a
│ │ ├── src
│ │ ├── test
│ │ └── deps.edn
│ └── b
│ ├── src
│ ├── test
│ └── deps.edn
├── build.clj
└── deps.ednIn this structure we have two packages - a and b where package b depends on package a.
Note
Run kmono query to inspect the workspace package graph and see how packages relate
This project demonstrates a workflow where:
- Packages are built and released when PR's are merged to master.
- Only packages that have changed since their previous version are build and released.
- The project uses conventional-commits and package versions are derived from commits.
The above requirements aren't needed to make use of kmono - this just serves to demonstrate a particular workflow and how you might use kmono to achieve it.
The build and release workflow described above is entirely encapsulated in the build.clj file using tools.build and
kmono-* APIs.
Packages can be built by running:
clojure -T:build buildAnd the built packages can then be released by running
clojure -T:build releaseFor both building and releasing you can add the :skip-unchanged true argument to only build and release packages that
have changed since their last release. The idea being that you would pass this by default during CI.
clojure -T:build build :skip-unchanged trueThis behaviour hasn't been hard-coded into the build process so that one might run just build locally during
development to build all packages.
Have a look at the example GitHub workflow file for how you might set up your CI pipeline for release.
To run the tests for each package you can run the command
# Run `clojure -M:test` in each package that has a `:test` alias.
kmono run -M :test
# Only run `clojure -M:test` in package a.
kmono run -M :test -F '*/a'Each respective packages' :test alias will then be appended to the command when it is run, like so: clojure -M:test.