Update Build to incorporate version number in Rust and Node.js Packages #40
Conversation
There was a problem hiding this comment.
Much better approach than the one I took. I've added PR to development of #11
tools/src/version.ts
Outdated
| await writeTomlManifest(packageTargetPath, version); | ||
| } | ||
| else { | ||
| logger.fatal(`Unsupported package target: '${packageTargetPath}'.`); |
There was a problem hiding this comment.
When I was debugging for Windows, this print was not displaying. However, when I changed it to logger.info(), it started working. I also tried giving nx the --output-style=static flag, but it didn't work.
There was a problem hiding this comment.
Hmm, OK. Perhaps the default level doesn't include fatal. I'll try it with logger.error(). Also, perhaps it should be more fatal and the build should fail. I'll take a look at whether you can inform Nx that the build should fail via the API.
There was a problem hiding this comment.
I've updated this so that it now reports the failure to Nx which then fails the build.
This PR implements #11 by adding a custom Nx Executor that will first compute a SemVer compatible version number; and then use it to update the appropriate
'package.json'and'Cargo.toml'files.The version number is based on the major and minor values defined in a new
'version.json'file that is present in the root of the repository. This file will be used to control the product version that we require a build for, while the Nx Executor will suffix the version with either: a) the commit height for releasable branches, or b) the current commit id for all other branches.Updating the version numbers is an explicit task. It is run via
npm run set-version(which should be run before thebuildorpackagescript variants). I would expect this to be typical in a CI context.