Can we adjust Travis settings on pull requests?

Plone Support Add-on Development
1

Continuing the discussion from How to view detailed travis flake8 errors?:

I wonder if we could adjust the way Travis is configured for our repos.

I too want the highest level of code quality, but it is a problem when Travis prevents merging a PR because code-analysis thinks that logic in code I have not touched nor changed is too complicated.

So far I have modified code in files I did not want to change, only because flake8 was complaining about lines being over 79 chars or an extra space being "needed" after a comment character.

But it is not right that I should be forced to modify logic in another file (again a file I did not touch in my PR). This is a big problem because:

The end result is that my PR will not get merged, my contribution will not be accepted, and I will have wasted a lot of time.

Can we:

  • configure Travis to warn, but not block merging of PRs
  • configure Travis to report the code-analysis errors, rather than making each of us run it locally just to find out the details of the flake8 errors it found
  • configure Travis to complain (or possibly block) merging of code that the PR modified, ignoring unmodified code
  • configure Travis in a "strict" way only on the github.com/plone organization, but not so much on the collective?
2

That's something that can be configured per repo, either on .travis.yml or buildout.cfg.

IMHO, I would advise to enable it, fix all the errors reported, and only after that make it mandatory.

Enabling QA but not fix it right away is pointless, as it just adds noise.

As usual though, it goes for each main developer to decide what they want to enforce on their repos.

1 Like
3

the problem is flake8 plugin ecosystem: behavior is changed from time to time and things appear broken because plugins versions are not pinned.

this is how we deal with that:

  • GitHub is configured not to accept any PR that is not passing all tests
  • Travis configuration mut be equivalent to local development configuration
  • when code-analysis fails I review and take note of the failures: you can fix everything on a different PR or, if changes are trivial, you can include them on the same PR
  • things that imply a refactor of other parts the code must not be done; you can skip them by using usual flake8 mechanism: for instance # noqa: C901
2 Likes
4

the problem is flake8 plugin ecosystem: behavior is changed from time to time and things appear broken because plugins versions are not pinned.

This is exactly what happened to us a week ago in some projects. Sometimes we create a new branch, fix the code-analysis than rebase the PR we were working with it. It depends on the taste, but I think the @hvelarde suggestion is a good compromise.

1 Like