ci: merge travis matrix, add salt-lint & rubocop to lint job

[myii]

• Semi-automated using feat: merge travis matrix, add salt-lint & rubocop to lint job myii/ssf-formula#60

---

Essentially, this PR is quite simple:

1. Convert the lint stage into a job that is run concurrently with the rest of the matrix.
2. Add salt-lint to the lint job.
3. Add rubocop to the lint job.

The details are easier to explain commit-by-commit.

---

refactor(travis): merge lint stage into the test stage

• Nothing new here, just a pure refactor to merge the lint stage into the test stage matrix.
• Even when we first introduced the lint stage, there were ideas to run it first, to get the quickest feedback to PR authors and maintainers.
• With the merge into the matrix and making it the first job, we get the best of both worlds.
• https://travis-ci.com/saltstack-formulas/template-formula/builds/130839797.

---

ci(travis): run salt-lint during the Lint job

• This was mentioned by @dafyddj on Slack, starting from:
  • https://freenode.logbot.info/saltstack-formulas/20191004#c2723464
• After a bit of work with the upstream maintainers, it's ready for use with our formulas.
• Basis for the git ls-files invocation:
  • Credit: @sblaisot
  • https://freenode.logbot.info/saltstack-formulas/20191004#c2724272

---

ci(travis): run rubocop during the Lint job

• Useful to lint our Ruby files as well (viz. InSpec).

---

fix(rubocop): add fixes using rubocop --safe-auto-correct

• First set of fixes automated by rubocop.

---

fix(rubocop): fix remaining errors manually

• Remaining fixes made manually.

[baby-gnu]

Great, it was really painful to wait so long to see a lint problem.

Thanks.

[myii]

So an update: I've run this against every formula using the ssf-formula. They've all tripped up for one reason or another. Every... single... one! I was expecting that but to make this process a bit more palatable, I'm going to split each linter into a separate job, so it's easier to find what each formula is failing on. Then it will be easier to make a plan about how to tackle these lint issues.

---

@n-rodriguez On a separate note, any feedback about the Ruby issue I asked above?

[myii]

Yes, that's better. Most are failing both but some are at least passing salt-lint, e.g.:

• https://travis-ci.org/myii/telegraf-formula/builds/595308560
• https://travis-ci.org/myii/locale-formula/builds/595308706
• https://travis-ci.org/myii/keepalived-formula/builds/595308887

Seems like most of the lint fixes are going to be for rubocop.

[myii]

OK, using allow_failures will help get around this problem:

• https://travis-ci.org/myii/telegraf-formula/builds/595335217

So there will be two types of .travis.yml that will be propagated:

1. The ideal: all of the linters in one job, like this PR.
2. Second job: Have a separate job for rubocop, which will use allow_failures.

I can do that above using ssf-formula, probably using the TOFS feature.

We should insist that salt-lint passes for every run, so I'll do that with each PR that's created from this process.

@daks @baby-gnu @dafyddj @aboe76 Thanks for taking out time to review this.

[saltstack-formulas-travis]

🎉 This PR is included in version 3.3.2 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[n-rodriguez]

@myii

@n-rodriguez On a separate note, any feedback about the Ruby issue I asked above?

Sorry for the late answer : usually I conform to https://github.com/rubocop-hq/ruby-style-guide#method-invocation-parens and https://github.com/rubocop-hq/ruby-style-guide#method-invocation-parens-internal-dsl and generally speaking to the whole guide itself.

Between :

describe file('/etc/postgresql/9.1/main/pg_hba.conf') do
  its('content') { should match(%r{local\s.*?all\s.*?all\s.*?md5}) }
  its('content') { should match(%r{host\s.*?all\s.*?all\s.*?127.0.0.1\/32\s.*?md5}) }
  its('content') { should match(%r{host\s.*?all\s.*?all\s.*?::1\/128\s.*?md5}) }
end

VS

describe file('/etc/postgresql/9.1/main/pg_hba.conf') do
  its('content') { should match %r{local\s.*?all\s.*?all\s.*?md5} }
  its('content') { should match %r{host\s.*?all\s.*?all\s.*?127.0.0.1\/32\s.*?md5} }
  its('content') { should match %r{host\s.*?all\s.*?all\s.*?::1\/128\s.*?md5} }
end

I prefer the second version.

[myii]

@n-rodriguez Thanks for the confirmation, that's what I went with in the end.

[myii]

@dafyddj @n-rodriguez Interesting note about the parentheses. In the case with should match (i.e. regex), it requires them otherwise it triggers:

• https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Lint/AmbiguousRegexpLiteral

Which probably explains why the InSpec documentation had them in that example.