Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Switch to using GitHub actions for CI (#351)
https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing https://www.jeffgeerling.com/blog/2020/travis-cis-new-pricing-plan-threw-wrench-my-open-source-works On Nov 2 Travis-CI introduced a new pricing model for their free tier offering. Those on this tier would now be limited to 1000 build minutes a month. This would start to be rolled out across accounts imminently. Defra's seems to have been updated November 9 because by the end of the day all builds stopped. When you went to Travis-CI a message was shown stating > Builds have been temporarily disabled for private and public repositories due to a negative credit balance. Please go to the Plan page to replenish your credit balance. It's going to take some time to decide and agree whether we will move to a paid-for option, or choose to start rolling our own. We don't like the idea of having no automated CI during this unknown period. A number of people caught up in this change have suggested [GitHub Actions](https://docs.github.com/en/free-pro-team@latest/actions) as an alternative. So this change moves the project from Travis to GitHub to handle our CI Because of the dependence on selenium based tests we also had to make a number of other changes ** Update chrome headless capybara driver code We spent ages trying to get the selenium based tests to run in GitHub Actions. All our initial efforts were focused on thinking there was something we needed to do in the environment. Start xvfb, set special chromedriver settings, grab the latest chromedriver etc. This was even though lots of posts noted that this was no longer needed as GitHub's `ubuntu-latest` build comes with tools like these pre-installed. We then started looking at how the driver was being registered. It turns out that a recent update to the Capybara gem required us to update how we were registering the driver. Switching to the pre-registered `:selenium_chrome_headless` got us from no passing selenium tests to all but 4. So we then reviewed the [source code](https://github.com/teamcapybara/capybara/blob/master/lib/capybara/registrations/drivers.rb#L27) for what [team capybara](https://github.com/teamcapybara) were doing. By combining that with existing args we were using that again lots of posts advised, we finally got it working! ** Remove mini-test reporters Whilst the progress bar format is nice, its unnecessary. Plus it does not work well with the GitHub action. ** Silence puma for Capybara tests Whenever we run `bundle exec rails test` at some point we see this in the test output ``` Capybara starting Puma... * Version 5.0.4 , codename: Spoony Bard * Min threads: 0, max threads: 4 /home/vagrant/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/puma-5.0.4/lib/puma/server.rb:94: warning: deprecated Object#=~ is called on Proc; it always returns nil * Listening on http://127.0.0.1:37836 ``` It seems to be triggered by hitting a test that requires javascript. That and the solution I actually found on an [RSpec issue](rspec/rspec-rails#1897). We still get the following error appearing ``` /home/vagrant/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/puma-5.0.4/lib/puma/server.rb:94: warning: deprecated Object#=~ is called on Proc; it always returns nil ``` But we are hoping this will be fixed in the next version of Puma.
- Loading branch information
1 parent
b8310ef
commit 44055c4