This change mandates a particular version of Node.js when running
`npm install`. When using a version of Node.js that does not meet these
expectations, a warning will be emitted to the user to let them know
that they are using an unsupported version of Node.js
Change-Id: I3f9bcf8be483a80b5882d65b034c6655013df19f
Signed-off-by: Chris Kay <chris.kay@arm.com>
Standard Version was not bumping the package metadata files as it
should have been. It's not clear to me why, but there is an open
[GitHub issue][1] for documenting this behaviour.
[1]: https://github.com/conventional-changelog/standard-version/issues/506
Change-Id: Ie89a81272fe507a3d2e1cd33c6ac1bdcc8ac3d75
Signed-off-by: Chris Kay <chris.kay@arm.com>
This change replaces cz-conventional-changelog with cz-commitlint, which
automatically configures Commitizen using our commitlint configuration
file. Currently, we use some manual Javascript magic to load our
Commitizen configuration into commitlint (the opposite of what's
introduced by this change), which can be removed.
With this change, we also move our commitlint configuration into a
new `changelog.yaml` file. This file holds the same data as `.cz.json`
previously did.
Change-Id: I14ff2308f1a0b2b293c2128b28ca2df578ce9c1c
Signed-off-by: Chris Kay <chris.kay@arm.com>
These fields were not updated accidentally on the v2.6.0 release.
Change-Id: I215105da618ff6f72057eaa40a34ff4b24f7ee36
Signed-off-by: Chris Kay <chris.kay@arm.com>
This change introduces a new NPM run script to automatically generate
the release changelog, as well as bump version numbers across the
code-base and create the release tag.
This script runs [Standard Version] to execute this, which is a tool
designed around automating substantial parts of the release process.
This can be done by running:
npm run release -- [<standard-version args>]
Standard Version expects the project to adhere to the [Semantic
Versioning] convention which TF-A does not, so you may need to specify
the version manually, e.g.:
npm run release -- --release-as 2.6.0
Individual steps of the release process may also be skipped at-will,
which may be necessary when, for example, tweaking the changelog:
npm run release -- --skip.commit --skip.tag
Standard Version is configured by the `.versionrc.js` file, which
contains information about the Conventional Commits types and scopes
used by the project, and how they map to the changelog.
To maintain continuity with the existing changelog style - at least to
the extent possible in the move from manual to automatic creation - a
customized changelog template has been introduced, based on the
Conventional Commits template provided by Standard Version.
This template package extends the Conventional Commits template package
by introducing support for parsing the Conventional Commits scopes into
changelog sections, similarly to how they were previously organized.
[Standard Version]:
https://github.com/conventional-changelog/standard-version
[Semantic Versioning]: https://semver.org
Change-Id: I5bafa512daedc631baae951651c38c1c62046b0a
Signed-off-by: Chris Kay <chris.kay@arm.com>
This tool is used to generate changelogs, tag repositories and bump
version numbers across the code-base. In preparation for the v2.6.0
release of TF-A, we will be incorporating it into our release workflow,
with the hope that it can reduce some of the workload involved going
forward.
After this change our dependency license situation is as follows:
```
$ license-checker --summary
├─ MIT: 249
├─ ISC: 43
├─ Apache-2.0: 6
├─ BSD-2-Clause: 3
├─ (MIT OR CC0-1.0): 3
├─ BSD-3-Clause: 2
├─ 0BSD: 2
├─ (MIT OR Apache-2.0): 1
├─ BSD*: 1
├─ CC-BY-3.0: 1
└─ CC0-1.0: 1
```
Change-Id: Ie41443045ecff22f322d155a4bed8ab5d92208cd
Signed-off-by: Chris Kay <chris.kay@arm.com>
Introduces the `name` and `version` fields to the NPM package metadata
file, which are used by Standard Version.
Change-Id: I5266465f746bf29805f36cd94b5e5c20417d7fd0
Signed-off-by: Chris Kay <chris.kay@arm.com>
This change adds the `license` field to our `package.json` file, which
allows some license checking tools to analyze our dependencies for
license incompatibilities.
The current state of our licensed dependencies is as follows:
```
$ license-checker --summary
├─ MIT: 198
├─ ISC: 31
├─ Apache-2.0: 5
├─ (MIT OR CC0-1.0): 3
├─ BSD-3-Clause: 2
├─ BSD-2-Clause: 2
├─ 0BSD: 2
├─ (MIT OR Apache-2.0): 1
├─ CC-BY-3.0: 1
└─ CC0-1.0: 1
```
Change-Id: I7b9dae1c9f732c7f7491b5d6557dd193b894d70c
Signed-off-by: Chris Kay <chris.kay@arm.com>
An indirect dependency of Commitizen (`merge`) is currently failing the
NPM.js auditor due to vulnerability CVE-2020-28499. This commit moves
the minimum version of Commitizen to 4.2.4, which has resolved this
vulnerability.
Change-Id: Ia9455bdbe02f7406c1a106f173c4095943a201ed
Signed-off-by: Chris Kay <chris.kay@arm.com>
This change adds a configuration for commitlint - a tool designed to
enforce a particular commit message style - and run it as part of Git's
commit-msg hook. This validates commits immediately after the editor has
been exited, and the configuration is derived from the configuration we
provide to Commitizen.
While the configuration provided suggests a maximum header and body
length, neither of these are hard errors. This is to accommodate the
occasional commit where it may be difficult or impossible to comply
with the length requirements (for example, with a particularly long
scope, or a long URL in the message body).
Change-Id: Ib5e90472fd1f1da9c2bff47703c9682232ee5679
Signed-off-by: Chris Kay <chris.kay@arm.com>
This change adds Commitizen, an interactive tool for writing commit
messages, to the package.json file. This installs Commitizen within the
`node_modules` directory automatically when developers invoke
`npm install` from the root repository directory.
Additionally, this change adds a prepare-commit-msg Git hook which
invokes Commitizen prior to generation of the default commit message.
It may be exited with the standard ^C signal without terminating the
commit process for those who desperately want to avoid using it, but
otherwise should encourage developers to conform to the new commit style
without running into post-commit linting errors.
Change-Id: I8a1e268ed40b61af38519d13d62b116fce76a494
Signed-off-by: Chris Kay <chris.kay@arm.com>
Husky is a tool for managing Git hooks within the repository itself.
Traditionally, commit hooks need to be manually installed on a per-user
basis, but Husky allows us to install these hooks either automatically
when `npm install` is invoked within the repository, or manually with
`npx husky install`.
This will become useful for us in the next few patches when we begin
introducing tools for enforcing a commit message style.
Change-Id: I64cae147e9ea910347416cfe0bcc4652ec9b4830
Signed-off-by: Chris Kay <chris.kay@arm.com>
Jayanth Dodderi Chidanand
Chris Kay