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.
This change adds temporary debug code to track down why the beta
build didn't get triggered by outputting the OUTPUT string.
It also counts the lines we're outputting so that we can output
a newline in case we're not outputting anything.
The build agent already has the relevant `SENTRY_` environment variables
set in order to complete builds for all projects. Thus, we should
exclude these values from the xcode build. However, we need to ensure
that the `SENTRY_URL` and `SENTRY_ORG` variables are imported into the
xcode environment from the build agent environment.
This change allows branches from forked repos to trigger test builds.
Note: this will not be run automatically, but only when we manually
tell it to run in TeamCity.
1. Adds parsing of commit comments to extract PR title + number.
2. Uses `--first-parent` to exclude merges that are not to the
base branch. This means that if you merge a PR into another, that
child PR will not be listed in the history. From my perspective, this
is fine -- we prefer chained PRs to be merged bottom-up rather than
top-down, and this allows for PRs to be collapsed into one history
entry if we really want that anyway.
3. Cleans up the git log range to work correctly regardless of your
current branch.
4. Reads git log information from origin/base rather than base.
Note: this assumes that you have recently `git fetch origin` (or
`git pull origin`); that's up to you.
Relates to #5172.
Adds a report-history.sh script to help report on what changes will be
in the upcoming build. Uses the same strategy as we currently use to
grab pull request numbers for HISTORY.md.
Also fixes duplicate entries that sometimes appear in HISTORY.md due to
merges from master into PR branches.
Adds a report-history mode for version.js so we can examine the list of
changes that will be in the next release build for a release branch
(master, beta, stable-x.y).
How to run:
pushd resources/build/version
npm install
npm run build:ts
popd
node resources/build/version/lib/index.js report-history -t "$GITHUB_TOKEN" -b "$base"
* Note: Always run from repo root.
* Where $GITHUB_TOKEN is a personal access token
* Where $base, if specified is the branch to validate (default: master)
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.
