Add testing for Bazel browser setup #397
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
devversion
force-pushed
the
browser-misc
branch
5 times, most recently
from
732c3ef to
a25a177
Compare
devversion
added
the
action: review
|
@josephperrott this would fix the firefox shasum error in FW |
josephperrott
approved these changes
Feb 11, 2022
devversion
force-pushed
the
browser-misc
branch
from
a25a177 to
47b5bfd
Compare
The update script currently fails to detect the archive extensions for Firefox since the substituted version in the download URL causes no known extension to be discovered. The `97.0` period/dot for example throws of the `extname` detection.
Adds a test for the Bazel browser configuration.
Fixes an invalid geckodriver checksum caused by a previously invalid download (fixed in the previous commits).
This also fixes a pythion shebang issue with Linux: bazelbuild/bazel@2945ef5.
Updates the bazelignore to exclude more integration node module folders that could throw off tests when they exist locally. This can happen because symlinks would be rewritten to hardlinks when the tests are running locally in a sandbox --> resulting in e.g. `node_modules/.bin` to be broken for bazelisk which uses `__dirname` and relies on symlink resolution/following.
Updates the test job resource class to match with the CircleCI Bazelrc configurtion which explicitly sets the resources to `xlarge`. Note: Looks like this is also needed looking at CPU and RAM: https://app.circleci.com/pipelines/github/angular/dev-infra/123691/workflows/aba2854d-9866-4295-ad09-72e438a3fd8c/jobs/124876/resources
Firefox tests will run in the Bazel sandbox, but Firefox currently requires, regardless of us specifying a custom profile directory, that the default profile directory exists. I've tracked down the Firefox launch issue, created a standalone repro without Bazel for Darwin, and submitted: https://bugzilla.mozilla.org/show_bug.cgi?id=1754821#c3 Until then, we can just make the test run on CI like this. This seems to be a long-standing issue so it does not seem worth currently reworking the Bazel Karma rules, or browser setup to workaround this. Most of the time folks can just run without sandbox, have launched firefox before (resulting in the directory to be available), or they can use `--sandbox_writable_path`. In any case though, this is something we'd need to do as a follow-up. The goal currently is to just set up a CI job to ensure that the binaries are valid, and resolved by dev-infra.
devversion
force-pushed
the
browser-misc
branch
from
47b5bfd to
8617270
Compare
devversion
added
action: merge
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See individual commits. A lot of things were coupled as some issues just surfaced due to cache invalidation and new CI executors. All of these issues are confirmed locally and they are reasonable (so nothing was flakiness!)