Skip to content

Conversation

@mjl-
Copy link

@mjl- mjl- commented Jun 14, 2019

I tried just updating github.com/lib/pq to v1.1.1. The build system is a bit much compared to the code, I didn't get it running before deciding to try to switch to go modules. I'm now running this to monitor a postgres11 with SCRAM authentication.

I know the changes are big for just updating a lib/pq. But I wouldn't be surprised no pull request has been created for this so far because of the build tooling. This is more of a starting point, I haven't done anything with Travis CI tests. I can understand if you don't want to change how builds are done.

This could solve #231.

Repeated from the message in the first (main) commit:

Make building simpler:

  • move cmd/postgres_exporter to .
  • use go build, not mage
  • add a docker-compose file that spawns all postgres versions and run tests against each of them.
  • remove the tools directory with linting tools. i've run golangci-lint locally.
  • no copying of assets

Not done:

  • travis ci tests
  • running (passing) the existing integration tests
  • running golangci-lint automatically (instead of the old linters). but then probably run it through docker. the source has a lot of go dependencies, don't want to make our go.mod huge. the alternative is a separate tools dir and go.mod file (instead of a tools.go in the root dir).
  • increasing test coverage

mjl- added 2 commits June 14, 2019 15:35
…, and modernize to go modules

Make building simpler:
- move cmd/postgres_exporter to .
- use go build, not mage
- add a docker-compose file that spawns all postgres versions and run tests against each of them.
- remove the tools directory with linting tools. i've run golangci-lint locally.
- no copying of assets

Not done:
- travis ci tests
- running (passing) the existing integration tests
- running golangci-lint automatically (instead of the old linters). but then probably run it through docker. the source has a lot of go dependencies, don't want to make our go.mod huge. the alternative is a separate tools dir and go.mod file (instead of a tools.go in the root dir).
- increasing test coverage
shouldn't have been committed
@asherf
Copy link
Member

asherf commented Jun 15, 2019

FWIW, the build toolchain in this repo is challenging, it might be me though, since I am new to go and the ecosystem around it

@RobAtticus RobAtticus mentioned this pull request Aug 12, 2019
@wrouesnel
Copy link
Contributor

Superceded by 69a90e8 which resolves #304

@wrouesnel wrouesnel closed this Oct 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants