Currently Travis only allows you to specify a version of stable or beta.
It would be very useful to be able to specify a fixed version. This would avoid unexpected build breakages as and when the stable or beta tags are updated.
Because Chrome is an auto-updated software, “unexpected breakages” because of a version upgrade is a legitimate source of errors that it is your job to attend to. Since updates are frequent and spontaneous, it is also not useful to specify a specific version because it will get obsolete fast.
So rather than a specific version, it makes sense to allow to use a previous version to find out whether it is your code or the version update that caused the error.
Or rather, since they provide beta and the beta version is supposed to eventually become the next release, do use stable and beta and fix any errors from version upgrade on beta stage, before they are actually seen by your users running the stable version.
To the best of my knowledge, Google does not distribute older versions of Chrome. There are third-party archives that purports to do this, and you are free to work out a way to use them. However, I do not think it is a good idea to make in available for everyone.
1 Like
My perspective is not that I want to avoid attending to these, but rather controlling when I attend to them. I would much prefer to control the upgrade and deal with breakages at a time of my choosing.
It’s useful to know that a new or forthcoming version introduces new problems, but many times these are insignificant bugs. If we were able to fix the build to a specific version, the build wouldn’t break unexpectedly (seemingly out of nowhere), and we could tackle the aforementioned insignificant bugs at a time of our choosing (when we bump the fixed version).
1 Like
Why not mark the beta version build with allow_failures then? It will not “spoil” the overall build status yet show you that a problem is coming in the next release.
According to https://www.chromium.org/getting-involved/dev-channel, a new Chrome release is done about every 2-3 weeks. So you will have 2-3 weeks to attend to any such issue.
That’s certainly an option for us, although still not as ideal as being able to control when upgrades effect the build, which seems to be the option with most flexibility here.
I can also imagine other use cases for this feature request. In a previous job, we deliberately controlled the browser versions of our (internal) users. In this setup, the build should target the same fixed version our users are using.
Hello folks,
To provide some context, our Chrome addon is pre-configured to grab the stable or beta versions provided by Google. This means, changes between versions downloaded will affect your build.
There are a few workarounds you can implement as follows:
-
bundle exec chromedriver-update $version[1] - Manually extract and install your preferred chromedriver [2]
I hope this helps
[1] https://github.com/flavorjones/chromedriver-helper/issues/79#issuecomment-472281137
[2] https://www.ocadotechnology.com/blog/2019/1/14/how-to-use-chromedriver-with-travis-ci-for-selenium-tests
1 Like