Fixes#4558.
This makes a number of fixes to get the context help working correctly
in Keyman 14:
1. Adds support for `redirect:` header in help .md files so that we can
do redirects for the context content in Keyman for Windows help in the
lua filters.
2. Renames Keyman for Windows help files to .htm, because that's what
the .chm format is expecting, and what Delphi assumes for its .chm
integration, and thus splits the html and htm lua filters.
3. Renames and makes more consistent the various context help pages.
4. Adds redirects for all pages that have sufficient content on other
pages.
5. Fixes the instantiation of help in various Keyman for Windows forms.
6. Defaults to opening help from the Keyman source repo if the calling
app is running in the source repo (this is just a development-side
tweak that simplifies my life).
When running from source we set the environment to `local` when
reporting to Sentry. This change also adds the package version and
the tier as additional Sentry tags.
This is a follow-up of PR #4581.
This change modifies the reported version number for km-config:
if km-config is installed from a debian package, the package
version will be output as well, e.g.:
`km-config version 14.0.252-beta (package version 14.0.252-1+bionic1)`
Otherwise the output will be identical to before:
`km-config version 14.0.252-beta-local`.
This change also modifies the script that sets the version number so
that builds on Jenkins are now detected in addition to TC.
This fixes#4579.
Allows us to manually run a version increment, for example if there is
a problem with a release build such as running out of space on the
download server.
Fixes#4484.
tsysinfox64 was being signed, but too late in the build
process as it is embedded into tsysinfo.exe. There was
code to sign it earlier, but that was being skipped due
to a missing build flag. This has been a problem for
some time.
This is necessary to be able to distinguish between a newly triggered
tagged build and a retriggered tagged build. The first tag param gets
saved between builds, but then we need a second parameter that doesn't
get saved that tells us if this build is a retriggered one.
Fixes#4201.
This adds a comment to pull requests with information about which build
a particular PR will be landing in, based on the HISTORY.md we have
already updated.
