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
Build and use tip-of-tree Chromium content shell on bots #12416
Comments
Raising the importance of this- We've slowed down the integration of Blink rolls as we switch to being based on the beta branch. We should have a way to stay on top of dev/canary. Added this to the M7 milestone. |
I think we should go in another direction. I think we should tests dart2js on something more stable, i.e., chrome beta, and I think we should test it in browser, not using content shell. I still see the need for this (and for testing dart2js on dartium) Here is my proposal: |
+1 on chrome dev channel. It'd be nice if a switch to a new dev version showed up as a separate line on the Dart build bot, so we can easily see whether breakage was due to upstream changes. Is that doable? dartium TOT will be behind chrome dev and beta, so it won't add much value to run dart2js tests there. Or are you suggesting for its content shell? |
Any reason the dart2js chrome dev channel on FYI? I do like having some main bots on dev channel as it lets us see what is coming before it's too late (assuming many of our developers are on beta channel). I have not seen much difference between content_shell and chrome other than test execution speed (and a few things such as rAF). I definitely prefer content_shell for local testing but either should be sufficient on the bots. |
The reason for dart2js chrome dev channel should go to FYI is this: We do have a way to eliminate this, but that require us to roll chrome manually (which is probably fine). If that is the case we can have dev channel on the main waterfall. We can script up the rolling. Basically we would store the binaries in gcs and fetch them based on a config file that we keep in the dart repo - to roll: upload the new version to gsc and update the config file in the dart repo. There is no easy way for us to get separate lines in the waterfall without doing it this way. |
Removed this from the M7 milestone. |
Removed this from the Later milestone. |
Removed Oldschool-Milestone-Later label. |
We are no longer using content shell. |
Can we build Chromium content shell from tip-of-tree (or perhaps http://dev.chromium.org/developers/how-tos/get-the-code#TOC-LKGR) on a semi-regular basis and use that for our dart2js tests?
Ideally, using a new content shell would trigger a separate line in the waterfall, so we could see that new failures are due to the new content shell.
Today, we're seeing failures (e.g., "int is not int") only when we do Dartium rolls.
The text was updated successfully, but these errors were encountered: