Fixes#8586.
All npm publish actions in the repository are now run as part of the
Developer release build, hosted at present by kmc, until we setup a
higher-level build script to do it.
Adds a 'pack' action which mirrors 'publish' for all npm packages.
Removes unnecessary dev dependencies of models-templates and
models-wordbreakers from kmc-model.
Web Release build CI step has been updated to check for presence of
.build-builder.
Improves build script performance by:
* using built-ins wherever possible (e.g. string splitting)
* eliminating redundant code
* using absolute (to $KEYMAN_ROOT) rather than relative paths to avoid realpath
* removing unnecessary `npm run` calls
BEFORE | AFTER
-------------------------------|----------------------
time ./core/build.sh --help |
real 0m2.116s | real 0m0.874s
user 0m0.578s | user 0m0.198s
sys 0m0.984s | sys 0m0.289s
-------------------------------|----------------------
time ./web/build.sh --help |
real 0m3.523s | real 0m0.757s
user 0m1.166s | user 0m0.320s
sys 0m2.273s | sys 0m0.455s
-------------------------------|----------------------
time ./web/build.sh -d |
real 1m34.750s | real 0m59.974s
user 0m9.721s | user 0m6.284s
sys 0m19.652s | sys 0m13.202s
@keymanapp-test-bot skip
Fixes#7582.
Because of https://github.com/npm/cli/issues/3466, we must publish our
internal dependency @keymanapp/keyman-version. This change adds a common
builder function builder_publish_to_npm in build-utils-ci.inc.sh to help
with that task, which should be adopted by other scripts that need to
publish to npm, in the future.
For now, responsibility for publishing keyman-version is delegated to
kmlmc. In the future, we will move this to a single top-level build
action that publishes all npm modules across the entire repo for the
given version.
* `builder_has_action` renamed to `builder_start_action`
* `builder_report` renamed to `builder_finish_action`
* `builder_has_action` created to be a silent test for the action
* Added reasonably comprehensive documentation.
Fixing up a number of minor bits and pieces identified during demo:
* invalid action or :target would not be picked up if paired with a
valid one (e.g.: build:foo should not have worked)
* colors defined in both shellHelperFunctions and build-utils were
problematic; able to remove them from shellHelperFunctions because
all references included both scripts
* builder_has_action and builder_report now allow both `action:target`
and `action :target`
* keyman-version/build.sh did not have working test action...
builder_init was unnecessarily and inconsistently duplicating
builder_describe and builder_parse functionality. Removing it -- all
scripts should use builder_describe and builder_parse instead, which
gives us more flexibility and consistency into the future.
Adds support for :target and --option to the builder_() functions in
build-utils.sh, along with a consistent way of describing command line
parameters in short-hand form, so we can avoid the display_usage getting
out of sync with actual command line parameters.
I opted to tweak the existing usage slightly, reversing parameter order
for `builder_report`, so that we could extend `builder_report` cleanly
to support targets.
The new builder_() functions are `builder_describe` and `builder_parse`,
which should be used in place for `builder_init` where you want to
provide more detailed command-line options (for many scripts, the
defaults provided through `builder_init` may suffice).
`builder_describe` lets you set a single-line description of the script,
along with a list of parameters: `actions`, `:targets` and `--options`.
Options may also specify a shorthand form, e.g. `--option,-o`. Each
parameter may optionally include a short description, separated by
space(s) from the parameter name.
build-utils.test.sh tests the functionality of the various functions,
and provides some examples of using them.
Defaults:
* If a target is not specified in `builder_describe`, a standard target
of `:project` will be available.
* If the user does not pass an action on the command line, then `build`
will be used.
* If the user does not pass a target on the command line, all targets
will have the actions applied.
Note, it is possible to have targets which do not use all actions. These
may be still be specified, but can be ignored. For example, `test:tools`
may not be an action:target that you handle in the script. At this time,
the builder_() functions do not attempt to check for this.
Starts to resolve the chaos of putting version numbers into every
package.json file.
Adds a new keyman-version package which mimics the
version information in build-utils.sh. This will eventually replace
resources/web-environment.
Fixes the build for the lexical model compiler tools to remove refs to
package.json version and use keyman-version instead.
More fixes coming in a follow-up.
