-
-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(developer): build.sh for developer #11421
Conversation
User Test ResultsTest specification and instructions
Test Artifacts
|
# | ||
# builder_publish_to_pack and builder_publish_to_npm are similar: | ||
# * builder_publish_to_npm publishes to the public registry | ||
# * builder_publish_to_pack creates a local tarball which can be used to test | ||
# If --npm-publish is set: | ||
# * then builder_publish_npm publishes to the public registry | ||
# * else builder_publish_npm creates a local tarball which can be used to test | ||
# | ||
# Usage: | ||
# ```bash | ||
# builder_publish_to_npm | ||
# builder_publish_npm | ||
# ``` | ||
# | ||
function builder_publish_to_npm() { | ||
_builder_publish_npm_package publish | ||
} | ||
|
||
function builder_publish_to_pack() { | ||
_builder_publish_npm_package pack | ||
function builder_publish_npm() { | ||
if builder_has_option --npm-publish; then | ||
# Require --dry-run if local or test to avoid accidentally clobbering npm packages | ||
if [[ $VERSION_ENVIRONMENT =~ local|test ]] && ! builder_has_option --dry-run; then | ||
builder_die "publish --npm-publish must use --dry-run flag for local or test builds" | ||
fi | ||
_builder_publish_npm_package publish | ||
else | ||
_builder_publish_npm_package pack | ||
fi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that this gets referenced by a lot of the child scripts, especially in the earlier files. Figured I'd highlight this as reference, as the merge of builder_publish_to_npm
and builder_publish_to_pack
is significant.
Also, I see that this conditions upon a non-implicit builder option - --dry-run
; that's an interesting decision, but I can understand it. (non-implicit: --dry-run
is not automatically available for all builder scripts, unlike --debug
and --verbose
.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hear you on this. tl;dir: I don't have a great answer. It's a bit repetitious for now but we can easily revisit in the future if we need to.
More details...
I could upgrade --dry-run
to a global option but I'm hesitant because it won't work on most scripts, so that's confusing (and I don't think we want to start supporting --dry-run
everywhere either -- busywork with little benefit). --debug
and --verbose
work nearly everywhere.
One option I considered is pulling this out to be an exported DRY_RUN variable. That could avoid us defining it on every script that does publishing.
FWIW, I do plan to using the option more later on for any other actions that send files to other systems (e.g. when we deploy to downloads, app store, play store, etc ad infinitum).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a lot here, so here's a partial review: I've looked over all the common/
+ common/windows
file changes. Hopefully the feedback's useful, given my comparatively limited knowledge of Windows & Developer build structure.
COMMON_OUTLIB="$KEYMAN_ROOT/common/windows/lib" | ||
|
||
if builder_is_debug_build || [[ $VERSION_ENVIRONMENT == local ]] || [[ ! -z ${TEAMCITY_PR_NUMBER+x} ]]; then | ||
# We do a fast build for debug builds, local builds, test PR builds but not for master/beta/stable release builds |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the difference between a "fast" build and one that isn't? I'm lacking context, since I'm not usually working with Windows or Developer source.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fast build in this context is currently only used when building installers -- reducing compression level which is really slow:
keyman/resources/build/win/wix.inc.sh
Lines 11 to 17 in 3ecc958
if [[ $GO_FAST == 1 ]]; then | |
# for debug builds, we turn off compression because it is so hideously slow | |
# for test builds, we also turn off compression | |
WIXLIGHTCOMPRESSION=-dcl:none | |
else | |
WIXLIGHTCOMPRESSION=-dcl:high | |
fi |
keyman/resources/build/win/zip.inc.sh
Lines 5 to 9 in 3ecc958
if [[ $GO_FAST == 1 ]]; then | |
"$WZZIPPATH" a -mx1 "$@" | |
else | |
"$WZZIPPATH" a -mx9 "$@" | |
fi |
"$DEVTOOLS" -ri | ||
} | ||
|
||
builder_run_action reset do_reset |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reset
? First time I've seen that as an action name in one of our scripts.
Lacking context here - what's the intended difference between reset
and clean
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reset just removes all the Keyman packages and paths from the Delphi IDE. It's kinda ugly, and it is legacy that we never really use. I copied it across but we could probably remove it altogether.
Relates to #11317. All projects now have a build.sh. Still need to work on inst/, remove old Makefiles, and update CI.
…ld scripts also, remove old Makefiles
This finishes the changes for all build infrastructure for Keyman Developer to use build.sh.
Now builds from a clean repo: developer/src/build.sh configure build test publish * Splits kmbrowserhost into kmdbrowserhost for Developer; this means that Developer Browser Host now inherits the Developer settings rather than the Keyman for Windows settings, and simplifies distribution and management. The only difference between the two is in the startup code so this seems like a good split. * Cleanup of various build scripts and dependencies.
Use a new flag `--npm-publish` in conjunction with `publish` action, so that the default will always be to `npm pack` if the new flag is not specified. This flag is also guarded in the actual npm publish code to ensure that it can only run in the appropriate CI alpha/beta/stable environment, and not in local or test. This then also removes the separate `pack` action. Also removes legacy boilerplate from a number of build scripts.
Also some more script cleanup and ensure common/core packages are also published.
A round of cleanup and consistency for Developer build scripts.
Additional shared script resources for Developer and Windows, refactor of a code signing function, refactor of clean step in build.sh.
781d154
to
8b2070c
Compare
Test Results
Steps to reproduce:
https://github.com/keymanapp/keyman/assets/19683059/11bc7a35-e403-4df5-a3e5-87be360211e1 |
Thank you @dinakaranr. The issue you experienced is being tracked at #11486. I think apart from that, the install went well, so we can go ahead with merge on this soon. TEST_DEVELOPER PASSED for all other use cases. |
Changes in this pull request will be available for download in Keyman version 18.0.42-alpha |
Fixes #11317.
Now builds from a clean repo:
Splits kmbrowserhost into kmdbrowserhost for Developer; this means that Developer Browser Host now inherits the Developer settings rather than the Keyman for Windows settings, and simplifies distribution and management. The only difference between the two is in the startup code so this seems like a good split.
Cleanup of various build scripts and dependencies.
TODO:
User Testing