Comments (2)
But internally when we decide to update "//testing/web/browsers:chrome-linux" to a new browser version, we can identify all users who the change breaks and notify them of the breakage (and potentially even fix the breakage). In the open source case that is much more difficult, and when I push out new versions of rules_web, I don't want to see people delaying adopting them because it happens to switch a browser version to a version that breaks their tests (and similarly when a new browser version is pushed out, I don't want users to delay adopting it because I haven't updated rules_web, and I don't want to make new releases of rules_web just because a new browser version is available).
And even if I did include the version numbers in the browser, which versions should I include? When can I delete a reference to an old version from the repository (or do I have to keep every version forever)? How do I deal with browsers with multiple channels with different release schedules (e.g. Chrome has at least stable, beta, and dev channels, and I can see valid arguments for testing against any or all of these)?
In Google, my team has made decisions about handling all of these issues, but those decisions were possible because we can readily identify every user of every browser we have defined. And even with that, we get flack for the decisions we make (everybody always seem to want more browser versions to test against, and always complain when by testing against more browser version they see increase flakiness) and sometimes make mistakes (i.e. deleting a browser version while it still has users, or upgrading a browser version to one that introduces new problems for users). And we essentially use 1 full-time head count (on rotation through our team) to manage browser updates.
from rules_webtesting.
You're absolutely right. We don't have the global choo-choo for testing on GitHub. So I would honestly just keep the old versions around forever. If those old browsers aren't being used, the only cost should be parsing the http_file
and adding it to a hash map.
In order to make this happen, we would ideally want a distinct package for each version of each browser. We would probably want the version numbers to be the same as caniuse.com which will be intuitive to users.
So maybe what I would say is:
web_test_suite(
name = "browser_test",
browsers = [
"@io_bazel_rules_web//browsers/chromium/v54",
"@io_bazel_rules_web//browsers/not_hermetically_sealed/firefox/v49",
],
local = 1,
test = ":browser_test_wrapped",
)
from rules_webtesting.
Related Issues (20)
- Flag --incompatible_disable_depset_items will break rules_webtesting in a future Bazel release
- Flag --incompatible_no_implicit_file_export will break rules_webtesting in a future Bazel release
- Unable to load file '...versioned:browsers-0.3.2.bzl': file doesn't exist
- Cannot build `//...` with Bazel 2.0.0
- Chromium test are failing HOT 2
- Coverage support? HOT 1
- Usage within Docker - "bind() failed: Cannot assign requested address (99)" HOT 4
- Update chromium version HOT 1
- Document and fix releaser.sh
- `jasmine_web_test_suite()`
- Debuggable browsers out-of-the-box
- Chromium arm64 provided can't be executed due to spaces in its path. HOT 2
- firefox times out in Github Actions HOT 6
- Flag --incompatible_config_setting_private_default_visibility will break rules_webtesting in Bazel 7.0 HOT 7
- Flag --incompatible_disable_starlark_host_transitions will break rules_webtesting in Bazel 7.0 HOT 3
- configurable attribute "out" in @io_bazel_rules_webtesting//go/wtl/main:main doesn't match this configuration
- Version tags after `v0.2.0` are missing the `v` prefix and no longer usable in `go.mod`
- Updating browser versions and doing a release?
- Transient test failues when running web_test_suite HOT 2
- rules_webtesting is failing with Bazel@HEAD in CI HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rules_webtesting.