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.
Starts to resolve the chaos of putting version numbers into every
package.json file.
Adds a new keyman-version package which mimics the
version information in build-utils.sh. This will eventually replace
resources/web-environment.
Fixes the build for the lexical model compiler tools to remove refs to
package.json version and use keyman-version instead.
More fixes coming in a follow-up.
This starts the reorg required for splitting the lm worker into its own
module. Tests are still not working. But builds are going.
Some decisions to be made around the final path for wrapping of the
code. I think it may be possible to do something a whole lot more
elegant by moving the wrapping process into the KMW build and leaving
the LM Worker output as a pure tsc output -- given only KMW wants the
wrapped worker anyway (tests aside). The actual wrapping code could
still be in the lm-worker folder.
Fixes#6320.
Part 1 of moving from lerna to a simpler, maintained monorepo solution,
using TypeScript Projects and NPM Workspaces.
There is more work to be done here. At this point, KeymanWeb builds and
runs without errors, but the built file is substantially different,
mostly in include order.
Using TypeScript Projects, we move away from the need to run build
scripts in various locations for almost all the Typescript modules.
TODO: Embedded versions and tests have not been verified.
TODO: developer/server is not yet verified.
TODO: developer/js (needs a rename!) is not yet verified.
TODO: Currently, the predictive-text folder needs refactoring to move
the construction of the worker wrapper out of the Predictive Text build
and into the final assembly of keymanweb.js (as it should be valid to
run it as a separate .js anyway).
TODO: Most of the `<reference>` paths need to be re-verified. Ideally
there should be no references outside the current module for any given
.ts.
TODO: The embedded vs browser vs node (headless) builds should be tidied
up for consistency so that it's obvious what depends on what. This is
currently messiest in the predictive-text folder, where the output names
diverge from the filenames and the various files are mixed in the same
folder (as evidenced by the exclusions listed in each tsconfig.json).
TODO: `npm install` should be removed from most build scripts and
instead `npm ci` (#6196) should be run only once from the top-level
folder for any given build. I've had eliminated side-effects from the
`install` action for npm, which makes it easier to reason about state.
TODO: verify_npm_setup and related functions can probably be eliminated.
TODO: most of the build scripts should be largely eliminated for web.
TODO: several ts projects use inconsistent output folders.
TODO: it may be possible to generate a .d.ts for models/types so that
we can use a consistent reference for those as well.
TODO: build.sh, tsconfig.json should always be in the module's top-level
folder, not in a subfolder such as src (e.g. see input-processor/src,
keyboard-processor/src, web/source).
TODO: resources/web-environment should be in common/web.
TODO: other js node_modules imports should be wrapped like es6-shim.
TODO: fix up the publish code for npm modules
TODO: eliminate version numbers from package.json if possible?
Whew, that's most of the stuff I noticed!
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)
