We initially used the default progress formatter when we first started building with Travis for our CI. When we then integrated with SonarCloud we switched the format to output a JSON file as that was what it needed. This meant if we got any rubocop issues it was no longer possible to see them in the build output. You would have to check SonarCloud.
Recently we have been getting a few projects fail because bundle exec rubocop --format=json --out=rubocop-result.json was returning exit code 1. As we couldn't immediately recreate the issue locally we assumed something might be broken with rubocop or our setup and chalked it up for further investigation. At the same time, we made sure our project defra-ruby-style was using the latest version of rubocop and pushed a new release. This triggered a number of broken builds across our projects which forced us to investigate the whole issue now.
What came to light was
rubocop does allow multiple formatters to be specified
bundle exec rubocop --format=json --out=rubocop-result.json returning exit code 1 was valid. It was our local passing runs that were invalid
On this basis, we're going through all our repos and updating the Travis config to use an updated rubocop command
This will mean we'll not only provide what SonarCloud needs, but we'll see immediately if the failure is because rubocop thinks there has been a violation. Hopefully, this will stop us getting confused in future!
We initially used the default
progressformatter when we first started building with Travis for our CI. When we then integrated with SonarCloud we switched the format to output a JSON file as that was what it needed. This meant if we got any rubocop issues it was no longer possible to see them in the build output. You would have to check SonarCloud.Recently we have been getting a few projects fail because
bundle exec rubocop --format=json --out=rubocop-result.jsonwas returning exit code 1. As we couldn't immediately recreate the issue locally we assumed something might be broken with rubocop or our setup and chalked it up for further investigation. At the same time, we made sure our project defra-ruby-style was using the latest version of rubocop and pushed a new release. This triggered a number of broken builds across our projects which forced us to investigate the whole issue now.What came to light was
bundle exec rubocop --format=json --out=rubocop-result.jsonreturning exit code 1 was valid. It was our local passing runs that were invalidOn this basis, we're going through all our repos and updating the Travis config to use an updated rubocop command
This will mean we'll not only provide what SonarCloud needs, but we'll see immediately if the failure is because rubocop thinks there has been a violation. Hopefully, this will stop us getting confused in future!