Update .travis.yml to solve PostgreSQL issues with new base images

[Alex-Vol-SV]

Travis CI updated the base images so the hacky PG 10 install is no longer needed and on top of that is failing the builds.

[coveralls]

Pull Request Test Coverage Report for Build 124

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 71.983%

---

Totals
Change from base Build 89:	0.0%
Covered Lines:	256
Relevant Lines:	331

---

💛 - Coveralls

[Alex-Vol-SV]

Looks like I need to lint the code and fix some violations in style. Now that the build works it failed in the style checks.

[SkUrRiEr]

@tdmalone This looks good to me, however there's something wrong with the CI checks (how do we have two separate Travis CI instances?) so I can't merge it.

I'll leave it to you to sort this out.

[SkUrRiEr]

Looks like I need to lint the code and fix some violations in style. Now that the build works it failed in the style checks.

The style issues aren't because of your changes, so no need to fix them. (in this PR)

[Alex-Vol-SV]

There are style issues that were not in my changes but not the "todo" warnings. The build was failing the style check, I suspect a newer version of eslint is used with more checkers? Regardless, without the style fixed this build will not pass Travis CI check and will not be mergable.

I can try to find out where the second CI build is triggered from, not really sure where that would be to be honest.

[SkUrRiEr]

There are style issues that were not in my changes but not the "todo" warnings. The build was failing the style check, I suspect a newer version of eslint is used with more checkers? Regardless, without the style fixed this build will not pass Travis CI check and will not be mergable.

The build isn't failing, I don't believe linter warnings actually fail it.

I can try to find out where the second CI build is triggered from, not really sure where that would be to be honest.

That's a job for Tim when he gets back. I'd just merge this manually, but I'm only 99% certain that this is correct and I'd like another set of eyes on it.

[Alex-Vol-SV]

The style check was failing on my other PR due to my changes. This comment was out of place for this PR. Sorry for the confusion.

For what it is worth, I made the changes based on the Travis CI documentation. In fact I cut/pasted the recipe from the docs verbatim.

[SkUrRiEr]

For what it is worth, I made the changes based on the Travis CI documentation. In fact I cut/pasted the recipe from the docs verbatim.

This is the only project I am involved with that uses Travis CI, so I lack the confidence to click the big "Merge" button, simple as that =)

[Alex-Vol-SV]

Not a problem, I am in no rush to get this merged. I use it in my instance from my github anyway.

It would help getting this merged to decouple the other two PR that depend on it and include this commit to get them building.

I will let @tdmalone decide how to handle the 3 PR, I can decouple them into two separate changes plus this one if this one is merged first to fix the cause of the build failures due to the platform change.

[Alex-Vol-SV]

I believe this explains the two builds we see.

As the master branch is not buildable I think we will get this cleared after this PR is merged. This would be the behavior from Travis testing both the target merge and the PR branch in isolation.

I was wrong, this is the real cause and it is something @tdmalone has to change in the Github branches configuration. The link has the full details.

[SkUrRiEr]

~Seems legit. I'll merge this manually as it's CI stuff only.~

I can't, it won't let me due to the CI failure. @tdmalone?

[Alex-Vol-SV]

This might require merge from git instead of the Github GUI. If this gets merged I believe the CI builds will start working and enable the rest of the PR to be ready for merge.