Github provides since august 2019 a new way to orchestrate any workflow, based on any event : Github Actions. A lot of developers migrates to this for their CI, because itโs (almost) free and fully integrated with github (no need to register to a new service for CI !).
The setup for a Ruby on Rails app with some features tests based on Capybara and some javascript is quite simple with the apparition gem (it works out of a box, without any specific configurations).
You can find an example of a working CI configuration here (this example use some caching, rubocop and brakeman).
One day, my CI stopped working : I had some js features tests which failed ( but not on my computer ). I was like โ Damn, remote debugging headless chrome tests seems to be pretty hard ๐ฌโ.
And yes, it was not an easy process ๐โฆ thatโs why I wrote this post today.
Finding a tool to reproduce the fail scenario
In my computer, failing tests are green, so I have to find a way to reproduce it.
I find a tool named act, which seems
to be a great fit for my needs : it uses Docker (like Github Actions) and read
Github Actions configuration files in .github/workflows
to reproduce the exact
behaviour of github actions.
However, I had multiple issues with it ๐
- First, I does not resolve tag well, and failed on my second step.
- Second, I had an issue on a env variable which was not set
- And the last one which led me to seek to an another solution :
The (painful) error:
To eliminate this warning, please install libyaml and reinstall your ruby.
My reaction ๐
I gave up and tried something else, which I knew will be more tricky : remote debugging ๐พ
Remote debugging
I found a github action that can create a tmate session on the host system : action-tmate
All you have to do itโs to put the step just before the rspec step, push on github, and connect to a ssh session.
When you open the action, youโll see the information to connect to this session:
FYI, It will loop until you (or Github) decide to stop the container.
In my case, I had to see whatโs going on my headless browser. Thanks to apparition, itโs possible to takes screenshots, so I put this line just before one of my failing assertion:
All I need to do is to connect to the remote session, run the failing test
and get the screenshot (thanks to transfer.sh, scp
and
rsync
does not work on tmate.io)
Here is my remote screenshot ๐
On this test, one of my perform_some_actions
is to toggle the content by
clicking on the element (example below, same screenshot but on my computer)
Clearly the action of toggling the content does not work on the CI.
My clicking action from my capybara test:
And my actual DOM:
I use StimulusJS to trigger some javascript (rails way!) (and some Tailwind CSS).
I suspect that
Capybara tries to click on the div, but not on the 2 last divs which triggers
the actual toggle (divs with data-action="click->content-toggle#toggle"
)
I tried to harden my clicking action by targetting the exact div like this:
I pushed on my debugging branch to trigger the build with my tmate action enabled (in order to run this test exactly) and guess what : it worked ๐๐
Conclusion
- act seems promising, Iโll definitely watch the evolution (be able to debug actions in local is definitely a nice to have!)
- Take screenshots and upload them in order to inspect exactly whatโs happen on your remote session, transfer.sh is a great tool for this
Have a pleasant day ๐