@rocketmakers/infrastructure

Sets up standard infrastructure for Rocketmakers projects.

Contents

• Development - notes on how to do development
• Release process - notes on the release process

Development

The project assumes you use the following git flow:

• feature branches - Local development branches
• develop - Main development branch on origin
• release - Published branch

Before pushing any branch, the project is built using make, tested with jest and linted with eslint on your local environment. If any of these fail, the push will be blocked until they're fixed. Your push will also be blocked if the commited built files don't match the artefact build from commited source code.

Test pipelines are run on every pushed branch, which test the same as the pre-push check, across supported node versions (currently 12, 14, 16 & 18).

Merge requests should be made to develop.

Testing npx scripts

You should write unit tests in the _tests folder to test the functional behaviour of your scripts. As noted above, these will be run frequently to ensure that breaking changes don't slip in.

As well as unit tests, it is possible to test npx scripts in anger, by locally globally installing them:

> npm i -g
> npx . infrastructure
Hello, world!
> npm un -g

Release process

There are pipelines set up in the boilerplate to target the branch release. When you are happy with your project and want to push it to npm, there's a few steps to complete.

Initial npm publish

You have to do a manual initial publish to npm to set up the project on their end.

First, find someone to add you to the rocketmakers organisation on npm - ask in the #developers channel if you aren't already. Next, make sure you are logged into npm on the command line. To check if you're logged in already, run npm whoami, if not run npm login and follow the steps. You will be emailed a OTP to login.

Then, on the command line run

npm publish --access public

This will push your local branch(!) but connect it to the repo. We have to mark this initial push as public, because scoped packages are private and paid for by default.

Versioning

With appropriate setup, this project uses commitizen to enforce conventional commits. Thanks to this, there is automated version bumping available. Run npm version to update the version number in appropriate places. This will also generate a change log in CHANGELOG.md, according to the commit messages. Run this before merging to release, as the release pipeline will fail if it attempts to release a version number that already exists.

Further releases

After the project exists on npm, merges to the release will automatically run a pipeline that tags git, pushes to npm and publishes documentation to docs.rocketmakers.club. When you want to release, make a merge request from develop to release, and once it is merged, sit back and wait for the pipelines!