Commit Graph

551 Commits

Author SHA1 Message Date
Joey Perrott 7d3f5043e1 build: fix assumed aliases in rebase-pr script (#37050)
The local rebase-pr script assumes the existence of specific git
aliases.  Instead this script should rely on the full written out
command instead.

PR Close #37050
2020-05-13 15:59:19 -07:00
Andrew Scott 420c179b39 build: update dependencies to use typescript 3.8 and angular 9.1 (#36329)
Update the typescript version to 3.8 as well as the Angular version to
9.1, which is the one which added TS 3.8 support.

PR Close #36329
2020-05-05 16:52:43 -07:00
Joey Perrott b4df19c029 build: update release precheck to rely on ng-dev for bazel stamping (#36925)
Migrate from using tools/bazel_stamp_vars.js to ng-dev to obtain
the current version name in the pre-check script.

PR Close #36925
2020-05-05 12:03:21 -07:00
Joey Perrott 6046e86506 build: update setup-rbe.sh script to accept non google.com/angular.io (#36846)
Previously the setup-rbe.sh script did not allow accounts that did
have domains of angular.io or google.com.  Since we add emails from
other domains into everyone@angular.io, we are unable to be certain
in the script that the account is not actually a member of the
required group.  This change adds the option to choose to continue
with an email account logged in which we cannot verify by domain.

PR Close #36846
2020-05-04 12:45:48 -07:00
Joey Perrott cebd4fada7 build: use sh instead of exec for release scripts (#36862)
Previously the exec command was used, however the exec command would
exit the original calling script regardless of the whether exit was
called.  This caused the release script to always exit after the
pre-check phase.

PR Close #36862
2020-04-29 13:04:43 -07:00
Joey Perrott fc1b557d98 build: run pre-check before publishing (#36527)
Previously, our process included running the pre-check script before
releasing.  With our new publishing process this was dropped.  This
change adds in automatically executing this check before publish for
both next and latest

PR Close #36527
2020-04-22 17:07:49 -04:00
Andrew Kushnir 5db8d93fe5 build: fix the compare master and patch script output (#36749)
Currently the commit message and corresponding version are flipped, which makes it hard to review the changes. This commit updates the script to properly recognize the order of arguments.

PR Close #36749
2020-04-22 00:23:57 -04:00
Andrew Kushnir 535c249f3a build: update `REQUIRED_BASE_SHA` in merge script to `commit-message` script update commit (#36750)
Updating `REQUIRED_BASE_SHA` for master and patch branches to make sure PRs that we merge are rebased after `commit-message` validation script update (to make sure the `lint` CI job fails in case a PR contains commits with invalid commit messages).

PR Close #36750
2020-04-21 21:58:23 -04:00
Andrew Scott d7e9d8746a build: list feat commits in patch branch in relase review script (#36651)
PR Close #36651
2020-04-17 18:16:36 -04:00
Andrew Kushnir fee316161d build: update `REQUIRED_BASE_SHA` in merge script to clang 1.4.0 upgrade commit (#36547)
Updating `REQUIRED_BASE_SHA` for master and patch branches to make sure PRs that we merge are rebased after clang 1.4.0 upgrade.

PR Close #36547
2020-04-09 16:00:31 -07:00
Joey Perrott f40d51733a fix(dev-infra): use commit message validation from @angular/dev-infra-private (#36172)
Prior to this change we manage a local version of commit message validation
in addition to the commit message validation tool contained in the ng-dev
tooling.  By adding the ability to validate a range of commit messages
together, the remaining piece of commit message validation that is in the
local version is replicated.

We use both commands provided by the `ng-dev commit-message` tooling:
- pre-commit-validate: Set to automatically run on an git hook to validate
    commits as they are created locally.
- validate-range: Run by CI for every PR, testing that all of the commits
    added by the PR are valid when considered together.  Ensuring that all
    fixups are matched to another commit in the change.

PR Close #36172
2020-04-06 09:28:52 -07:00
JiaLiPassion c5df9ce474 build(zone.js): update zone.js version to 0.10.3 (#36214)
PR Close #36214
2020-03-31 10:59:17 -07:00
Paul Gschwendtner fb92f5de1a build: fix @bazel/bazel to bazelisk leftovers (#36132)
A few leftovers from from `@bazel/bazel` to `@bazel/bazelisk` migration
are still there. This commit fixes those, so that the repository no
longer relies on `@bazel/bazel`.

PR Close #36132
2020-03-19 08:58:47 -07:00
Greg Magolan 2b6028b643 build: remove legacy integration test runner (#35985)
* integration tests target definitions in integration/BUILD.bazel updated to use a single dict
* payload tracking for integration tests updated to work under Bazel
* legacy integration_test CI job removed
* integration/run_tests.sh script no longer used in CI so it has been updated for running integration tests locally in the legacy way

PR Close #35985
2020-03-11 15:12:33 -07:00
Andrew Kushnir c98c6e80c8 build: adding a script to compare commits in master and stable branches (#35130)
Adding a script that compares commits in master and patch branches and finds a delta between them. This is useful for release reviews, to make sure all the necessary commits are included into the patch branch and there is no discrepancy.

PR Close #35130
2020-03-10 17:40:56 -04:00
George Kalpakas 82a6fc5ef9 build(docs-infra): use local version of Zone.js when testing against local packages (#35858)
In some cases, we want to test the AIO app or docs examples against the
locally built Angular packages (for example to ensure that the changes
in a commit do not introduce a breaking change). In order to achieve
this, we have the `ng-packages-installer` script that handles updating
a project's `package.json` file to use the locally built Angular
packages (and appropriate versions for their (dev-/peer-)dependencies).

Previously, `ng-packages-installer` would only consider the locally
built Angular packages (from `dist/packages-dist/`). However, given that
Zone.js is now part of the `angular/angular` repo, it makes sense to
also use the locally built Zone.js package (from `dist/zone.js-dist/`).
Otherwise, the tests might fail for commits that update both the Angular
packages (and related docs examples) and the Zone.js package. An example
of such a simultaneous change (that would have broken tests) is #33838.

This commit updates the script to install the locally built Zone.js
package (in addition to the Angular ones). The commit ensures that the
Zone.js package will always be available alongside the Angular packages
(i.e. that the Zone.js package will be built by the same script that
builds the Angular packages and that the `dist/zone.js-dist/` directory
will be cached on CI).

Note: This problem was discovered while enabling docs examples unit
tests in #34374.

PR Close #35858
2020-03-06 17:30:20 -05:00
Joey Perrott b42e2e0dff build: create dev-infra-private npm package (#35862)
Creates the scaffolding for an @angular/dev-infra-private package
which will not be published to npm but will be pushed to
https://github.com/angular/dev-infra-private-builds repo for each
commit to master.

The contents of this npm package will then be depended on via
package.json dependency for angular/angular angular/angular-cli and
angular/components.

PR Close #35862
2020-03-05 18:55:40 -05:00
Andrew Scott 1b8a66893e Revert "build(docs-infra): use local version of Zone.js when testing against local packages (#35780)" (#35857)
This reverts commit 7d832ae1001b6264bb7124086089e9e69c10c9b6; breaks CI
with error `Concurrent upstream jobs persisted the same file(s) into the workspace:`

PR Close #35857
2020-03-04 10:57:36 -08:00
George Kalpakas 7d832ae100 build(docs-infra): use local version of Zone.js when testing against local packages (#35780)
In some cases, we want to test the AIO app or docs examples against the
locally built Angular packages (for example to ensure that the changes
in a commit do not introduce a breaking change). In order to achieve
this, we have the `ng-packages-installer` script that handles updating
a project's `package.json` file to use the locally built Angular
packages (and appropriate versions for their (dev-/peer-)dependencies).

Previously, `ng-packages-installer` would only consider the locally
built Angular packages (from `dist/packages-dist/`). However, given that
Zone.js is now part of the `angular/angular` repo, it makes sense to
also use the locally built Zone.js package (from `dist/zone.js-dist/`).
Otherwise, the tests might fail for commits that update both the Angular
packages (and related docs examples) and the Zone.js package. An example
of such a simultaneous change (that would have broken tests) is #33838.

This commit updates the script to install the locally built Zone.js
package (in addition to the Angular ones). The commit ensures that the
Zone.js package will always be available alongside the Angular packages
(i.e. that the Zone.js package will be built by the same script that
builds the Angular packages and that the `dist/zone.js-dist/` directory
will be cached on CI).

Note: This problem was discovered while enabling docs examples unit
tests in #34374.

PR Close #35780
2020-03-04 08:35:26 -08:00
George Kalpakas 3f88de9407 build: move build scripts to dedicated directory (#35780)
This commit moves the build-related scripts
(`build-ivy-npm-packages.js`, `build-packages-dist.js` and
`package-builder.js`) to a dedicated directory to keep the `scripts/`
directory cleaner.

It also moves the logic for building the `zone.js` package to a separate
script, `zone-js-builder.js`, to make it re-usable. A subsequent commit
will use it to build the `zone.js` package when building the Ivy Angular
packages as well.

PR Close #35780
2020-03-04 08:35:26 -08:00
Paul Gschwendtner 5615928df9 build: no longer run tslint from within gulp task (#35800)
Switches our tslint setup to the standard `tslint.json` linter excludes.
The set of files that need to be linted is specified through a Yarn script.

For IDEs, open files are linted with the closest tslint configuration, if the
tslint IDE extension is set up, and the source file is not excluded.

We cannot use the language service plugin for tslint as we have multiple nested
tsconfig files, and we don't want to add the plugin to each tsconfig. We
could reduce that bloat by just extending from a top-level tsconfig that
defines the language service plugin, but unfortunately the tslint plugin does
not allow the use of tslint configs which are not part of the tsconfig project.

This is problematic since the tslint configuration is at the project root, and we
don't want to copy tslint configurations next to each tsconfig file.

Additionally, linting of `d.ts` files has been re-enabled. This has been
disabled in the past and a TODO has been left. This commit fixes the
lint issues and re-enables linting.

PR Close #35800
2020-03-03 09:20:49 -08:00
George Kalpakas ab8199f7c9 build: several minor fixes related to using `puppeteer` (#35381)
This is a follow-up to #35049 with a few minor fixes related to using
the browser provided by `puppeteer` to run tests. Included fixes:

- Make the `webdriver-manager-update.js` really portable. (Previously,
  it needed to be run from the directory that contained the
  `node_modules/` directory. Now, it can be executed from a subdirectory
  and will correctly resolve dependencies.)

- Use the `puppeteer`-based setup in AIO unit and e2e tests to ensure
  that the downloaded ChromeDriver version matches the browser version
  used in tests.

- Use the `puppeteer`-based setup in the `aio_monitoring_stable` CI job
  (as happens with `aio_monitoring_next`).

- Use the [recommended way][1] of getting the browser port when using
  `puppeteer` with `lighthouse` and avoid hard-coding the remote
  debugging port (to be able to handle multiple instances running
  concurrently).

[1]: https://github.com/GoogleChrome/lighthouse/blame/51df179a0/docs/puppeteer.md#L49

PR Close #35381
2020-02-18 12:42:47 -08:00
Greg Magolan acfd0edd38 test: use puppeteer in integration tests and to download correct chromedriver (#35049)
This means integration tests no longer need to depend on a $CI_CHROMEDRIVER_VERSION_ARG environment variable to specify which chromedriver version to download to match the locally installed chrome. This was bad DX and not having it specified was not reliable as webdriver-manager would not always download the chromedriver version to work with the locally installed chrome.

webdriver-manager update --gecko=false --standalone=false $CI_CHROMEDRIVER_VERSION_ARG is now replaced with node webdriver-manager-update.js in the root package.json, which checks which version of chrome puppeteer has come bundled with & downloads informs webdriver-manager to download the corresponding chrome driver version.

Integration tests now use "webdriver-manager": "file:../../node_modules/webdriver-manager" so they don't have to waste time calling webdriver-manager update in postinstall

"// resolutions": "Ensure a single version of webdriver-manager which comes from root node_modules that has already run webdriver-manager update",
"resolutions": {
"**/webdriver-manager": "file:../../node_modules/webdriver-manager"
}
This should speed up each integration postinstall by a few seconds.

Further, integration test package.json files link puppeteer via file:../../node_modules/puppeteer which is the ideal situation as the puppeteer post-install won't download chrome if it is already downloaded. In CI, since node_modules is cached it should not need to download Chrome either unless the node_modules cache is busted.

NB: each version of puppeteer comes bundles with a specific version of chrome. Root package.json & yarn.lock currently pull down puppeteer 2.1.0 which comes with chrome 80. See https://github.com/puppeteer/puppeteer#q-which-chromium-version-does-puppeteer-use for more info.

Only two references to CI_CHROMEDRIVER_VERSION_ARG left in integration tests at integration/bazel-schematics/test.sh which I'm not entirely sure how to get rid of it

Use a lightweight puppeteer=>chrome version mapping instead of launching chrome and calling browser.version()

Launching puppeteer headless chrome and calling browser.version() was a heavy-handed approach to determine the Chrome version. A small and easy to update mappings file is a better solution and it means that the `yarn install` step does not require chrome shared libs available on the system for its postinstall step

PR Close #35049
2020-02-11 13:16:52 -08:00
Paul Gschwendtner c4ad12c1c3 ci: remove components-repo-ci blocklist (#35115)
Previously we needed the `components-repo-ci` blocklist to disable
tests that were failing during the development of Ivy. Since we fixed
all those failing tests, and we don't want to regress, we can remove the
blocklist logic.

Resolves FW-1807

PR Close #35115
2020-02-06 15:32:33 -08:00
Igor Minar 722251da40 build: update scripts/release/post-check with the latest versions (#35151)
these files are used as a post-release smoke tests and haven't been updated to reflect recent depedency changes
and package additions.

PR Close #35151
2020-02-06 09:37:26 -08:00
George Kalpakas 519e9e1ae8 ci: minor PullApprove fixes/improvements (#35015)
This is a follow-up to #34814 to fix some typos in patterns and make
them more similar to the old patterns from `.github/CODEOWNERS`.

PR Close #35015
2020-01-29 12:23:47 -08:00
Greg Magolan dff4e1e19c refactor: simplify bazel saucelabs targets using karma pre-test wrapper and shared saucelabs connection between tests (#34769)
* Added a /tools/saucelabs/sauce-service.sh script that manages the sauce-connect as a service which is used by the karma-saucelabs.js wrapper to start the service.
* Added /tools/saucelabs/README.md that covers the details of SauceLabs karma testing with Bazel.

PR Close #34769
2020-01-28 13:47:00 -08:00
Paul Gschwendtner fa4ea34401 ci: rename `material-unit-tests` job to `components-repo-unit-tests` (#34898)
We rename the `material-unit-tests` job to `components-repo-unit-tests`
because the job runs all unit tests found in the Angular Components repository.
This includes the Angular CDK, Angular Material and more. Also the repository has
been renamed from `angular/material2` to `angular/components` in the past.

PR Close #34898
2020-01-23 13:29:02 -08:00
Greg Magolan 45ae62787a build: package-build & release scripts should handle new pkg_npm naming (#34736)
bazel query now using: kind("ng_package|pkg_npm", //packages/...)

PR Close #34736
2020-01-15 14:58:07 -05:00
Paul Gschwendtner c9f24e6a58 ci: overwrite angular/components yarn typescript resolution (#33717)
The components repository has a Yarn resolution to ensure that
dgeni-packages uses a specific TypeScript version. This resolution
causes the specified TS version to be considered as candidate for the
`@angular/bazel` peer dependency. Ultimately, Yarn decides to use
the TypeScript version from the resolution for `@angular/bazel`,
and builds will fail due to a version mismatch.

This is because `tsickle` will use the hoisted top-level TS
version (set to `3.7.4` ), while `@angular/bazel` uses the
version from the resolution (at the time of writing: v3.6.4)

PR Close #33717
2020-01-14 16:42:22 -08:00
atscott 7e9ac7650b Revert "build: package-build & release scripts should handle new pkg_npm naming (#34589)" (#34730)
This reverts commit 053b23d902.

PR Close #34730
2020-01-10 14:12:15 -08:00
Greg Magolan 053b23d902 build: package-build & release scripts should handle new pkg_npm naming (#34589)
bazel query now using: kind("ng_package|pkg_npm", //packages/...)

PR Close #34589
2020-01-10 08:31:59 -08:00
Paul Gschwendtner 6d3a25d897 ci: run acceptance tests on saucelabs with ivy (#34277)
Currently we only run Saucelabs on PRs using the legacy View Engine
build. Switching that build to Ivy is not trivial and there are various
options:

  1. Updating the R3 switches to use POST_R3 by default. At first glance,
  this doesn't look easy because the current ngtsc switch logic seems to
  be unidirectional (only PRE_R3 to POST_R3).

  2. Updating the legacy setup to run with Ivy. This sounds like the easiest
  solution at first.. but it turns out to be way more complicated. Packages
  would need to be built with ngtsc using legacy tools (i.e. first building
  the compiler-cli; and then building packages) and View Engine only tests
  would need to be determined and filtered out. Basically it will result in
  re-auditing all test targets. This is contradictory to the fact that we have
  this information in Bazel already.

  3. Creating a new job that runs tests on Saucelabs with Bazel. We specify
  fine-grained test targets that should run. This would be a good start
  (e.g. acceptance tests) and also would mean that we do not continue maintaining
  the legacy setup..

This commit implements the third option as it allows us to move forward
with the general Bazel migration. We don't want to spend too much time
on our legacy setup since it will be removed anyway in the future.

PR Close #34277
2019-12-16 07:43:41 -08:00
Joey Perrott 89ef77f750 ci: update sha of components repo for components unit test integrations (#34280)
Before updating to remove the compile build variable, we must update
the components unit test integrations to a sha  in the components
repo which no longer relies on the compile build variable.

PR Close #34280
2019-12-06 11:04:20 -08:00
Joey Perrott 4022376b3f build: update scripting and tooling to rely on define=angular_ivy_enabled instream of define=compile (#33983)
We need to migrate to using angular_ivy_enabled value to determine whether to use
Ivy or ViewEngine for package building scripts and for size-tracking and
symbol-extract tooling.

PR Close #33983
2019-11-26 16:38:40 -05:00
George Kalpakas 9b5299131b ci: remove change type from uploaded payload size data (#33987)
The change type was only recorded for `aio/` and was not correct anyway.
For example:
- It considered `package.json` changes as `application` (even if only
  `package.json` and `yarn.lock` had changed).
- It failed to account for changes in `@angular/*` dependencies, when
  using the locally built Angular packages (instead reporting them as
  `other`).
- It only looked at the last commit, so it failed to provide accurate
  information for multi-commit builds (which are rare, but possible).

For the above reasons (and because there is no straight-forward way of
fixing it), this commit removes the change type from the uploaded data.
If necessary, it is still possible to find the type of changes from the
uploaded info (e.g. extract the associated commits and look at their
changes using git).

PR Close #33987
2019-11-25 16:36:07 -05:00
George Kalpakas 9bc8864d03 ci: always track and check payload size data for angular.io (#33987)
As part of the `payload-size` npm script in `aio/package.json` (which is
run on CI), the sizes of the angular.io app bundles are checked to
ensure they do not exceed certain limits and are also uploaded to
Firebase to be available for later analysis. The uploaded data include
the type of the changes (dependencies only, application only, or both).
The type of changes is inferred by looking at the files that have
changed inside the `aio/` directory.

When the `payload-size.sh` script was first introduced, the only files
that could affect bundle sizes were inside the `aio/` directory.
Therefore, the script would skip uploading the data and checking the
sizes if no changes were detected inside the `aio/` directory.

However, this assumption stopped being valid over time. For example:
- We started tracking/checking bundle sizes when building the angular.io
  app with the locally built Angular packages (which live outside the
  `aio/` directory.
- Due to CircleCI limitations, the `CI_COMMIT_RANGE` environment
  variable (which is used for determining what files have been affected)
  stopped reflecting the whole commit range of the build and only
  included the last commit instead.

Based on the above, there were many cases were size data would not be
uploaded to Firebase, even when they may have been affected (because the
affecting changes were outside `aio/` - e.g. in framework packages).
This makes it harder to analyze size regressions, because important
data-points are missing.

Even worse, in these cases, the sizes were not even checked against the
specified limits, thus making it possible for size regressions to go
unnoticed (unless caught by other similar tests).

This commit fixes the `scripts/ci/payload-size.sh` script to always
track and check payload sizes for angular.io bundles.

NOTE: This change will result in more data being recorded (i.e.
      recording data when it is not possible for the bundle sizes to
      have been affected by the changes). This is still preferable to
      failing to record and/or check when sizes could have been
      affected.

PR Close #33987
2019-11-25 16:36:07 -05:00
Kara Erickson d752e26eb2 ci: tighten size threshold to 1% or 500 bytes (#33969)
The size diff threshold of 1% has proven to be too lenient for us
to catch size regressions in AIO. Since the AIO main bundle is
between 400-500 KB, a size regression must be between 4-5 KB before
it will cause the tests to fail. As a result, we may merge many
changes with smaller regressions of a few KB before the size test
eventually lets us know that the number has increased. The hope is
that lowering the threshold will help us catch the smaller
regressions during code review and prevent the size tests failing at
a random later time when someone catches the size "hot potato".

PR Close #33969
2019-11-22 16:51:41 -05:00
George Kalpakas 485ce640fd ci: use more descriptive names for published build artifacts (#33957)
In efbbae5a4, the `publish_packages_as_artifacts` CircleCI job was
created to publish the build artifacts of PR builds on CI. In a8f4f14bd,
its scope was expanded to also publish build artifacts on non-PR builds.

The published artifacts names are constructed based on the PR number
(e.g. include `-pr12345-`), so on non-PR builds the names do not reflect
the source branch (instead, they include `-prfalse-`).

This commit fixes this by using the current branch name. For example,
artifact names for the `master` or `9.0.x` branch will include
`-master-` and `-9.0.x-` respectively (instead of `-prfalse-`).
(NOTE: For PRs, where branch name is `pull/12345`, the branch name is
transformed to `pr12345`.)

PR Close #33957
2019-11-22 14:05:52 -05:00
Joey Perrott 346e1c14d9 build: update setup-rbe.sh script and documentation to remove http-remote-cache config (#33907)
We have determined that the upload time cost of remote caching via http is too costly
to be effective for our distributed usage scenario.  However this cost is still worth
it for us for Windows CI runs on a full cache hit move from a ~60 minute task to ~10
minutes.

It is worth noting that this remote http-caching is entirely separate from RBE caching
mechanisms.

PR Close #33907
2019-11-21 10:45:57 -08:00
Pete Bacon Darwin be58159550 build: ensure package-builder finds bazel (#33904)
Since `scripts/package-builder.js` gets run from the
`aio` folder sometimes, it is important to set the cwd
for the command that finds the bazel bin directory.

PR Close #33904
2019-11-19 11:40:19 -08:00
George Kalpakas e2cba6ed7d build: replace `fs` methods with ShellJS' `test('-d')` (#33895)
This makes the JS script more similar to the original bash script it
replaced (see #33854) and will be easier to follow for people that are
less familiar with Node.js scripting.

Discussed in:
https://github.com/angular/angular/pull/33854#discussion_r346949765

PR Close #33895
2019-11-18 09:10:16 -08:00
George Kalpakas 7eb3e3bce6 build: fix build scripts on macOS (#33854)
In #33823, `scripts/package-builds.sh` (which is used by both
`build-packages-dist.sh` and `build-ivy-npm-packages.sh`) was updated to
use `realpath`. It turns out that `realpath` does not exist on macOS, so
the build scripts do not work there.

In order to fix this (and also reduce the likelihood of introducing
similar issues in the future), this commit changes these bash scripts to
Node.js scripts (using [ShellJS](https://github.com/shelljs/shelljs) for
a cross-platform implementation of Unix shell commands where necessary).

PR Close #33854
2019-11-15 16:05:00 -08:00
George Kalpakas 695bb6ca87 build: fix build scripts on macOS (#33843)
In #33823, `scripts/package-builds.sh` (which is used by both
`build-packages-dist.sh` and `build-ivy-npm-packages.sh`) was updated to
use `realpath`. It turns out that `realpath` does not exist on macOS, so
the build scripts do not work there.

This commit fixes it by switching from `realpath $(pwd)/..` to
`dirname $(pwd)`, which does practically the same thing (in this
situation) and works on macOS as well.

PR Close #33843
2019-11-15 10:36:54 -08:00
George Kalpakas e25b256aa4 build: minor improvements to build script output (#33823)
- Move "Building packages" log above actual work (computing targets).
- Print corrent script name (`build-ivy-npm-packages.sh` would claim to
  be `build-packages-dist.sh`).
- Make logs of different operations a little more consistent.

PR Close #33823
2019-11-14 09:29:49 -08:00
George Kalpakas 2ce9cdab9d ci: publish tarballs for the zone.js package as CI build artifacts (#33733)
Since #33321, Angular packages have been persisted on each build as
CircleCI build artifacts (`.tgz` files), which can be used to install
dependencies on a project (for the purpose of testing or trying out a
change before a PR being merged and without having to build the packages
from source locally).

Previously, only packages published to npm under the `@angular` scope
were persisted as build artifacts.

This commit adds the `zone.js` package to the list of persisted
packages.

Fixes #33686

PR Close #33733
2019-11-12 09:55:17 -08:00
George Kalpakas 74b7d1ace1 test(ngcc): build `zone.js` from source in `scripts/build-packages-dist.sh` (#33733)
In #33046, internal uses of `zone.js` were switched to reference it
directly from source (built with Bazel) instead of npm. As a result, the
necessary scripts were updated to build `zone.js` as necessary. However,
some `integration/**/debug-test.sh` scripts were missed (apparently
because they are not used on CI, but only locally as helpers for
debugging the integration projects).

This commit updates the `scripts/build-packages-dist.sh` script to also
build `zone.js`, so that other scripts (such as the various
`debug-test.sh` scripts) can use it.

PR Close #33733
2019-11-12 09:55:16 -08:00
Joey Perrott bf10e98891 build: delete jenkins scripts (#33598)
PR Close #33598
2019-11-05 20:55:18 +00:00
Paul Gschwendtner 31116f0ced ci: re-enable material unit tests job (#33530)
The Material units tests job has been disabled with the
typescript upgrade PR since the components repository was
still on an old TypeScript version (due to cyclic dependencies
between the framework and components repository).

Since the components repository has been updated to `9.0.0-next.15`
and now uses the compatible TypeScript version, we can re-enable
ds

Related to this change, we need to ignore the `package.json`
engines when installing the dependencies of the components repo. This
is because the components repo already updated to NodeJS v12 and Yarn
v1.19.1. This is not the case for the CI setup of framework. For now,
since we don't want to change the dev setup (as it slows down
development), we temporarily disable the engines.

Additionally, the material unit tests job now depends on the actual
release packages (not on the ngtsc compiled ones). This is because
the components repo setup relies on NGCC being run. This is also
helpful for validating ngcc against the framework packages.

PR Close #33530
2019-11-01 17:38:39 +00:00
Joey Perrott c4695bb387 build: ensure that version stamping is applied when the npm_package publish action is called (#33512)
PR Close #33512
2019-10-31 10:21:41 -07:00