Currently when `yarn benchmarks run-compare` is used, the local
repository could be converted to a shallow clone. This is not
a problem but might result in confusion. We avoid this by
not performing a shallow fetch when a comparison is initiated.
The performance gains seem neglegible.
PR Close#50851
We already collect and report benchmark results for comparison runs, but
for normal benchmark runs we should do the same to make the results
more discoverable (and not in the middle of Bazel output).
PR Close#50816
`rev-parse` returns the original ref name in stdout, even if it wasn't
able to resolve the reference. This was preventing the upstream
resolution from never happening- causing `main` to be never resolved
to the actual SHA.
When we fetch e.g. `main`, the branch name will not be available
locally, and `rev-parse` will fail later. We can make the logic
more safe by just using `FETCH_HEAD` then.
PR Close#50767
If we try to resolve the benchmark compare ref (which may be just
`main`), we are just looking inside the PR branch- but that may
not include the `main` SHA. i.e. it's possible to run a comparison
where the PR is slightly behind of the `main` branch, or a comparison
commit from a different branch is used.
We fix this/ and simplify the logic by resolving the SHAs directly in
the TypeScript code, instead of relying on the rather brittle Bash.
Note that current solution still works, but we sometimes may not be able
to resolve to an actual SHA- causing issues as in 864bd72cb2
PR Close#50764
This commit creates a new script that solves the following use-cases:
- Running benchmarks. It's not trivial to figure out the benchmark
target names, and it's also easy to mess up the right Bazel flags.
- Performing comparisons. When e.g. working on a runtime senstive
change, it should be trivial to run benchmarks between the current
working stage, and a base revision (e.g. `main`).
The script takes care of both these use-cases and comes with a
prompt-based command line tool experience.
The script will also be used by a future GitHub action that can run
comparisons triggered via GitHub PR comment (by trusted team members).
PR Close#50745
We are no longer publishing Angular Bazel to npm, but we are still
using it in the components repo. We should still publish it to
benefit from e.g. the APF v16 changes.
PR Close#49583
This commit increases the threshold of payload size tracking tests from
500 bytes to 5,000 bytes, and from 1% to 5%. This is done to minimize merge
conflicts while still catching real regressions.
PR Close#49520
This commit does three things that all related and required to get
rid of `webdriver-manager`:
* Our puppeteer protractor setup in AIO relies on webdriver-manager
because we install a corresponding chromedriver based on the puppeteer
chromium version. We would like to get rid of this brittle setup.
* We don't use `puppeteer` in many places because we manage chromium and
the driver through Bazel. This commit removes the remaining puppeteer
usage and replaces it with the Bazel-managed canonical browser
* We need to migrate the AIO production URL tests to Bazel. These
weren't part of Aspect's migration. This is needed so that we can drop
puppeteer and use the Bazel browser setup.
* Migrates some at-runtime TS `ts-node` test setup to proper idiomatic
Bazel code. Needed because it depends on code that also had to be
migrated to Bazel given the production e2e test Bazel migration (above
points).
Note: The xregexp dependency had to be added to the root project because
`ts_library` does not support compilation deps from `@aio_npm`. This is
something we will fix anyway when we have a more modern toolchain!
PR Close#49025
We no longer need webdriver-manager as everything is tested
using Bazel with the Bazel-managed browsers and chrome/gecko drivers.
The drivers and browser binaries are managed as part of dev-infra's
shared browser/driver configuration in `bazel/browsers`.
PR Close#49009
After discussion initiated in the framework team (by kkostadinov),
the team has decided to not keeping the `components-repo-unit-tests`
job. This commit removes it.
PR Close#48521
The dev-infra build tooling is now decoupled from `ng-dev`. This will
make it easier to update `ng-dev` without necessarily needing to upgrade
the whole build system, Bazel etc. This is useful when e.g. new release
tool features have been added and should also be ported to active LTS
branches.
PR Close#46976
As there is little to no usage of RBE by individuals and we don't actively ensure
that the process and permissions are working for individuals the documentation is
best removed from the repo.
PR Close#46515
We need to switch the package builder to ESM or TS, like we did
in the components repo, but for now until we can, the release script
should work by loading the package builder CJS through the dynamic
import expression.
PR Close#46454
If the snapshot publish job is manually being restarted, the tag in the
snapshot repo might already exist and the job will fail. We can just
forcibly re-create the tag (even if it will be at the same revision).
We use force mode in a couple of other command as well, such as `git
push` of the actual tag and snapshot revision/SHA.
PR Close#46366
We recently had a couple of issues with the shallowing of snapshot
git repositories. In an attempt to fix this, parts of the publish
script of the COMP repo have been used, but variables have not been
updated properly.
This commit fixes an unbound variable, avoiding errors when snapshots
are published for a new branch (e.g. when we branch-off).
PR Close#46076
Use the absolute path for the artifacts directory, as well as encapsulate the clone
vs init logic to prevent it from changing directories.
Manually remove the shallow marker so that git does not recognize this as a shallow repo.
PR Close#45979
Rather than using git init to create an empty repo and then shallow fetch the
repo for a specific branch, we shallow clone the repository itself for the branch.
This prevents us from running into the issue of Github denying the push because it
comes from a shallow branch which does not map back to the repository.
PR Close#45975
It looks like because the primary branch for our ephemeral repos doesn't match the build repos
we are pushing to it causes errors around shallow clones. This attempts to prevent this.
PR Close#45974
Removes scripts and documentation for tools which are no longer
actively used and likely do not work anyway at this point.
All of our PR-related tooling has moved into the `yarn ng-dev` command.
The `PR_REVIEW` markdown file is deleted since it was soley about
the legacy review scripts and the PR review workflow also does not
seem like the common/standard workflow Angular team members follow.
PR Close#45868
Uploading payload size is unreliable from within Bazel. This is
because tests might not run for every commit, tests might have
been cached from a pull request RBE-build (causing payload uploading
to be skipped most of the time as every change comes from a PR)
We should disable the uploading as this is a fundamental problem
(good thing to note now) that we can solve with better payload
size tracking that we want to establish as part of dev-infra.
PR Close#45446
For quite some time now, since we started to use Bazel for integration tests, we
relied on some size tracking logic that did not actually fully work under Bazel.
It was thought that all the necessary CI push/PR information is available to the
Bazel test, but that was not the case. This was now fixed with the recent Rules NodeJS
v5 update where I made sure the `env.sh` variables are actually available before we
write them to the temporary file for the Bazel-access.
This now will unveil an issue because payload size goldens would start being based
on their branch name. e.g. the golden key in `13.3.x` should not be `master` but
`13.3.x`. This makes more sense than `master` as key, but makes things more
cumbersome and ideally we would not store the branch name at all (this is a larger
change though -- not worth now since we might refactor this anyway). For now we will
update the size tracking logic to always use `master` as golden key (like it worked
in the past year(s))
With the environment fix we now (again) start uploading payload size results to Firebase.
This did not work by accident either. The uploading logic is reliant on the CircleCI
commit range which is not working/reliable in upstream branches. This commit
removes this reliance on `COMMIT_RANGE` since it's not strictly necessary and
currently breaking renovate PRs. We can re-enable this when we have a solution with
CircleCI, or a workaround/resolution logic provided in e.g. `ng-dev ci determine-commit-range`.
PR Close#45444
.substr() is deprecated so we replace it with functions which work similarily but aren't deprecated
Signed-off-by: Tobias Speicher <rootcommander@gmail.com>
PR Close#45397
CI components test install the angular package from the local
version, but still use the zone.js from npm, so this commit let
components also install zone.js from local too.
PR Close#45277
Several people on the team (myself included) have had issues where the `webdriver-manager` step of the `postinstall` script fails on the first run, but work correctly on the second one.
These changes attempt to simplify the workflow by retrying the script up to 3 times before giving up.
PR Close#45252
To speed up the components CI job (avoiding it being a bottleneck in FW),
we will stop building everything in `src/...`, but rather only build targets
which are needed to run all tests within `src/...`.
This notably should avoid unnecessary NPM package building. Arguably that
part would also be valuable to have, but we already test the `ng_package`
rule in FW itself, plus we run snapshot tests in the components repo as well.
PR Close#44832
Setting the angular_ivy_enabled environment variable to True will default Bazel builds to use the Ivy
compiler rather than defaulting to ViewEngine.
PR Close#43862
Re-enables the building of the `src/dev-app` package in the components
repo when the components-repo-unit-test job runs. We previously disabled
the dev-app because it was not compatible with template typechecking of
ngtsc. This should be fixed now and can re-enable it.
This could be valuable for having some actual real test scenarios of
type checking.
PR Close#43798
The package builder script should respect the `BAZEL` environment
variable for running Bazel. If not set, it can fallback to bazelisk
from the `node_modules`. Respecting this variable allows for users
with a global `bazel` binary. This is desirable in some situations,
like on Windows, where running Bazel inside of the Yarn environment
seems slower than running a global variant. This could appear like that
because projects might use different Bazel versions. In some cases,
developers would want to use a single (already-warmed-up) instance of
Bazel instead of launching different versions using bazelisk.
(e.g. when switching a lot between repos like COMP, FW or CLI..)
In any case, it doesn't hurt providing this flexibility for advanced
use-cases. It's low-effort to maintain and is respected in COMP as well.
PR Close#43431
