This change moves the `build_is_ci_*` functions from
`resources/build/build-utils-ci.inc.sh` → `resources/builder.inc.sh`.
Fixes: #13885
Test-bot: skip
Previously the builder scripts defined a readonly `VERSION` environment variable for the Keyman version. That caused problems when another (external) script tried to define a `VERSION` variable. We encountered this problem when trying to move the TC build steps of a configuration into a single script (#13399) when we tried to source `~/.nvm/nvm.sh`.
This change uses a Keyman specific prefix for the version variables and renames `VERSION` → `KEYMAN_VERSION` etc. as well as `TIER` → `KEYMAN_TIER`. Unfortunately these variables are used in a lot of places, so this turned out to be a bit of a yak shave.
Sometimes a builder script can be redirected internally and then error
messages are lost in the redirect if the script fails. This sidesteps
that problem by reporting errors to stderr instead of stdout.
- remove `builder_is_running_on_ci` function since there already is a
similar `builder_is_ci_build` function
- use `GITHUB_ACTIONS` environment variable instead of `GITHUB_RUN_ID`
to detect if we're run be GitHub Actions
This adds the three additional functions `builder_is_running_on_ci`,
`builder_is_running_on_docker`, and `builder_is_running_on_gha` to be
able to detect if the build is running in a CI or CI-like container
environment.
If we're not running on TC we should output the start/end messages as
headings unless it's a child build. This was the previous behavior
before we added support for TC blocks.
Previously the builder scripts defined a readonly `VERSION` environment
variable for the Keyman version. That caused problems when another
(external) script tried to define a `VERSION` variable. We encountered
this problem when trying to move the TC build steps of a configuration
into a single script (#13399) when we tried to source `~/.nvm/nvm.sh`.
This change uses a Keyman specific prefix for the version variables and
renames `VERSION` → `KEYMAN_VERSION` etc. Unfortunately these variables
are used in a lot of places, so this turned out to be a bit of a yak
shave.
Test-bot: skip
This change adds support for TC blocks of service messages
(https://www.jetbrains.com/help/teamcity/service-messages.html#Blocks+of+Service+Messages)
and starts/ends a block in the `builder_start_action`/`builder_finish_action`
functions. We output the TC block service messages only if we're running
on TC, i.e. if the `TEAMCITY_GIT_PATH` environment variable is set.
Part-of: #13399
Test-bot: skip
Some additional items arose from this:
* Adds a command-line-tests unit test which does some basic sanity tests
on `kmc`.
* Cleans up some of the error reporting infrastructure in `kmc` to
ensure that thrown errors are handled better.
* Removes redundant subshell from `builder_run_action`.
Fixes: #12846
One of the traps prevents debugging a build script in
the `bashdb` debugger. This change skips trapping `err` and `exit`
when run under a debugger and so allows to debug the script with `bashdb`.
A lot of the `configure` actions rely on node dependencies and so call
`npm install`. Without a internet connection this hangs forever, even
if you had successfully installed the dependencies before and nothing
changed since then. This change adds a `--offline` parameter that passes
`--prefer-offline` to npm, which causes npm to use the cached
dependencies.
Also sets the `MESON_PACKAGE_CACHE_DIR` environment variable so that all
(sub-)projects share the same package cache dir. This will speed up regular
builds a bit (e.g. `developer/src/kmcmplib` and `core` both have `icu4c`
as a dependency), but will also help with offline builds.
`MESON_PACKAGE_CACHE_DIR` requires Meson 1.3, however older Meson
versions ignore this environment variable and simply continue to use a
cache per subproject, so will continue to work (minus offline builds).
Previously we didn't show the description for the target if the target
definition specified a an alternate folder, e.g. `:app=src/app`. This
change fixes this.
This top-level builder script will build as many projects as are
possible to build on the current platform. For example, iOS and macOS
projects can only be built on macOS; Windows and parts of Developer can
only be built on Windows.
Relates-to: #6268
Add `builder_describe_platform` function to builder.inc.sh, associated
documentation and unit test, and use it in Developer and Common build
scripts.
Relates-to: #11755
Previously with the right number of parameters that take values and the
right order it could happen that a parameter value got replaced by an
action when the script output the parameters. This change fixes this.
Fixes: #11676
The call to the command listed for `builder_run_action` was not properly
quoted, which meant that quoted parameters would have been corrupted,
for example:
builder_run_action clean rm -rf "temp folder/"
Would have run:
rm -rf temp folder/
When using module:target style dependencies, Builder would not track the
individual targets within the module, causing only the first target to
be built; subsequent dependency targets within that module would be
treated as already built.
This change means that builder will track individual targets within
the dependency. However, it is possible for targets to be built multiple
times if there a dependency listed for the entire module as well as for
the individual target within dependency, as in the following example,
where building project1 and project2 in one command would cause
module:mytarget to be built twice.
builder_describe project1 \
@/module
builder_describe project2 \
@/module:mytarget
This scenario should not break builds as they any configure+build
actions should be idempotent, but it could cause builds to be a little
slower, so should be corrected if identified. I do not currently plan to
further modify the dependency calculations to cater for this scenario.
Finally, if :mytarget is a child build, it is better to reference the
child module directly than the parent's target, for example:
builder_describe projec1 \
@/module/mytarget
This fixes the use of colors in the help output when `builder_term` is
used inside of `builder_describe` (e.g. `web/test.sh --help`). Previously
the escape sequences were not interpreted but directly output.
If you had an option with a parameter, e.g. "--outfile c,b", then the
"c,b" was being treated as a parameter for expansion, which caused it
to expand to e.g. "configure,build". Oops.
This sets us up to run all common/ and resources/ tests from a single
script, common/build.sh. This test will be run on each platform for all
changes made in common/ or resources/.
Also renamed files and paths for consistency in resources/ and updated
tests accordingly.
