Because BrowserStack tests are unreliable, I am disabling them for any
builds that are not specifically targeting web. Two ways that the tests
can be enabled:
1. Include '(web)' in the PR title
2. Include the label test-browserstack
This only impacts builds in the CI test environment, not anything else.
See build-utils-ci.inc.sh for helper functions for accessing PR
metadata, and build-utils-ci.test.sh for unit tests for this
functionality.
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...
This change also slightly modifies `echo_heading` and outputs a
mark. This will show to the left of the line as well as in the
scroll bar in a terminal in VSCode [[1]] and will help to find the
headings if you have a lot of output in between.
[1]:https://code.visualstudio.com/updates/v1_69#_setmark-sequence-support
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.
Fixes up scripts (except under /linux) to use `#!/usr/bin/env bash`
instead of `#!/bin/bash` or `#!/bin/sh` so that we don't end up with
the ancient version of bash supplied with macOS.
This became urgent with this PR, because of bash-4.xisms in
build-utils.sh, for example on line 572:
```
if [[ -v _builder_params[$e] ]]; then
```
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.
Adds run-xcodebuild function to wrap xcodebuild calls to keep logging
and error handling consistent. Currently used only by the iOS build; the
macOS build has a corresponding execBuildCommand function which does
pretty much the same thing (changing that would belong in a separate PR
I think and low priority.)
* Addresses some Typescript-specific breaking changes in destructured
types.
* Removes npm version calls and package*.json updates -- these are no
longer required.
* Adds resources/build/version as a workspace to root package.json.
* Runs `npm ci` on the repo root for resources/build/version.
* Adds additional logging.
Relates to #5816.
Moves folders under common/core/web to common/web:
* input-processor -> common/web/input-processor
* keyboard-processor -> common/web/keyboard-processor
* tools/recorder -> common/web/recorder
* tools/sentry-manager -> common/web/sentry-manager
* utils -> common/web/utils
Updates scripts and configuration to point to new folders.
Fixes#6391.
The issue here was quite nuanced: where we merged a PR, and then merged
the changes into an earlier PR, but left it open, the earlier PR could
end up getting the release information comment from keyman-server
instead of the later, merged PR. This was because the commit would
appear in both PRs, so GitHub would report on both of them.
This is not a 100% fix -- but it should stop the PR tagging on unmerged
pull requests. The one situation where this may leave a gap is where we
have multiple PRs merged on the same day, where a later PR's changes are
merged into an earlier PR; in this case I think it is possible that one
of the PRs will not get the informative version comment.
But given the current fix should avoid the more common situation, I am
comfortable to leave it as is for now. This is only informative data...
and a more complete fix is a distraction.
