This change moves the `build_is_ci_*` functions from `resources/build/build-utils-ci.inc.sh` → `resources/builder.inc.sh`.
It also adds documentation for them.
Fixes: #13885Fixes: #13886
# Keyman Conventional Commit suggestions:
#
# - Link to a Sentry issue with git trailer:
# Fixes: _MODULE_-_ID_
# - Give credit to co-authors:
# Co-authored-by: _Name_ <_email_>
# - Use imperative, present tense ('attach' not 'attaches', 'attached' etc)
# - Don't include a period at the end of the title
# - Always include a blank line before trailers
# - More: https://github.com/keymanapp/keyman/wiki/Pull-Request-and-Commit-workflow-notes
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
# Keyman Conventional Commit suggestions:
#
# - Link to a Sentry issue with git trailer:
# Fixes: _MODULE_-_ID_
# - Give credit to co-authors:
# Co-authored-by: _Name_ <_email_>
# - Use imperative, present tense ('attach' not 'attaches', 'attached' etc)
# - Don't include a period at the end of the title
# - Always include a blank line before trailers
# - More: https://github.com/keymanapp/keyman/wiki/Pull-Request-and-Commit-workflow-notes
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 makes use of the new builder script function to detect if the script is running on TeamCity. Also use the
`TEAMCITY_GIT_PATH` environment consistently to check if we're running on TC.
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
