Grouping is a nice feature, but it wasn't helpful here. If there's an error in rubocop for example, the rubocop section will be collapsed, and because we didn't close the group, the haml group was always open. So it wasn't clear where the error was.
Better to just show all the output, which isn't very long, so you can see where the problem is straight away.
Even better would be to add support for GitHub Actions annotations. I thought we used to have that turned on, not sure why it's not working now.
We can somewhat easily get it passing and integrate nice with reviewdog
by adding a TODO file for the rules that we had enabled, so that we
don't need to correct anything now, but we still get alerted for new
offenses. So I say let's keep it and enforce it from now on.
So that we can control the version we run without depending on external
actions, and so that we use a consistent version for all linters.
At the same time, unify to running the latest version of reviewdog,
0.21.0, which also involves changing the deprecated `fail_on_error` flag
previously used by prettier action to `fail_level`.
I think this is the more relevant wiki page for someone looking into
regenerating cassettes.
Also, no need to mention bitwarden explicitly, the wiki page already
explains everything.
In development, you may choose to use this script in your Git pre-commit hook.
Then you want the fastest possible execution to not be delayed in your
Git operations. While the default is the safest option, you can now
define your own optimised command to avoid loading the whole Rails app
environment.
This script is used by a developer whenever the Stripe gem is bumped by
Dependabot. I found myself always doing the same commands and thought
that they could be automated.
I'm not going as far as pushing back to the branch but we might do that
in the future?
This allows us to run the specs separately to generate the
documentation. It's more efficient this way and the separate swagger doc
file is easier to read.
The engine-specific swagger helper also allows us to simplify the spec
files.
Added an exception to our styleguide because it's intended and useful to
have a complete (lengthy) description of the API in one block.
