Current way of setting prometheus project to generate repo is tedious.
If you just go install packages described in README.md
it ends up with those (non buildable code)
```
../../../prompb/remote.pb.go:61:34: undefined: "github.com/prometheus/prometheus/vendor/github.com/gogo/protobuf/proto".InternalMessageInfo
../../../prompb/remote.pb.go:109:33: undefined: "github.com/prometheus/prometheus/vendor/github.com/gogo/protobuf/proto".InternalMessageInfo
../../../prompb/remote.pb.go:164:34: undefined: "github.com/prometheus/prometheus/vendor/github.com/gogo/protobuf/proto".InternalMessageInfo
../../../prompb/remote.pb.go:214:27: undefined: "github.com/prometheus/prometheus/vendor/github.com/gogo/protobuf/proto".InternalMessageInfo
../../../prompb/remote.pb.go:284:33: undefined: "github.com/prometheus/prometheus/vendor/github.com/gogo/protobuf/proto".InternalMessageInfo
```
The issue is that the guide presented in proto folder is asking to
install some GO packages. It does not mention from what version and
there is strong mismatch between those used to generate proto and those
that are vendored and used to run the code later...
The particular outdated packages in vendor are:
`github.com/gogo/protobuf` and `google.golang.org/grpc`.
Just updating vendor would be not enough, as it would only tmp fix.
I propose adding script that will parse version from vendor.json and install correct version.
Changes:
- Added script that uses packages in *exactly* the same version the Go code is build against later.
- Regenerated proto with those pinned deps.
- Updated REAMDE.md
- Added `make proto`Current way of setting prometheus project to generate code from proto files is tedious.
If you just go install packages described in README.md, it ends up with this (non buildable code)
```
../../../prompb/remote.pb.go:61:34: undefined: "github.com/prometheus/prometheus/vendor/github.com/gogo/protobuf/proto".InternalMessageInfo
../../../prompb/remote.pb.go:109:33: undefined: "github.com/prometheus/prometheus/vendor/github.com/gogo/protobuf/proto".InternalMessageInfo
../../../prompb/remote.pb.go:164:34: undefined: "github.com/prometheus/prometheus/vendor/github.com/gogo/protobuf/proto".InternalMessageInfo
../../../prompb/remote.pb.go:214:27: undefined: "github.com/prometheus/prometheus/vendor/github.com/gogo/protobuf/proto".InternalMessageInfo
../../../prompb/remote.pb.go:284:33: undefined: "github.com/prometheus/prometheus/vendor/github.com/gogo/protobuf/proto".InternalMessageInfo
```
The issue is that the guide presented in proto folder is asking to install some GO packages. It does not mention from what version and there is strong mismatch between those used to generate proto and those that are vendored and used to run the code later...
The particular outdated packages in vendor are:
`github.com/gogo/protobuf` and `google.golang.org/grpc`.
Just updating vendor would be not enough, as it would only tmp fix.
I propose adding script that will parse version from vendor.json and install correct version.
Changes:
- Added script that uses packages in *exactly* the same version the Go code is build against later.
- Regenerated proto with those pinned deps.
- Updated REAMDE.md
- Added `make proto`
Signed-off-by: Bartek Plotka <bwplotka@gmail.com>
Reduce the duplication of per-project specifics in the CircleCI config.
* Add docker repo variable, default to docker hub.
* Add make targets for docker push and tag latest.
Signed-off-by: Ben Kochie <superq@gmail.com>
* web: replace deprecated InstrumentHandler()
This change replaces the deprecated InstrumentHandler function by the
equivalent functions from the promhttp package.
The following metrics are removed:
* http_request_duration_microseconds (Summary).
* http_request_size_bytes (Summary).
* http_requests_total (Counter).
And the following metrics are added instead:
* prometheus_http_request_duration_seconds (Histogram).
* prometheus_http_response_size_bytes (Histogram).
* promhttp_metric_handler_requests_in_flight (Gauge).
* promhttp_metric_handler_requests_total (Counter).
* Update github.com/prometheus/common/route package
* web: refactor using the new prometheus/common/route package
If the GOBIN environment variable is set to a non-default location
relative to GOPATH, then promu will be built in this location and the
the build will fail because it tries to run $GOPATH/bin/promu.
See also issue #483 and #492
* promu: Use same go invocation as prometheus' for building
If you override $(GO) var in prometheus Makefile in order to use
a custom go binary you might encounter errors while building promu
as promu's Makefile $(GO) var is also defined to look for go in the
$PATH and you might end up using different go binaries for building
prometheus and promu.
This patch makes prometheus Makefile pass its $(GO) var to promu's makefile
as environmental variable.
Signed-off-by: Sylvain Rabot <s.rabot@lectra.com>
* Makefile: Allow $(GO) to be set with environmental variable
Signed-off-by: Sylvain Rabot <s.rabot@lectra.com>
* Makefile: Fix hardcoded call to gofmt
Signed-off-by: Sylvain Rabot <s.rabot@lectra.com>
* Test Longer Tests in Travis
Signed-off-by: Goutham Veeramachaneni <cs14btech11014@iith.ac.in>
* Make test Target Run All Tests
* Add test-short to run short tests
test is running all the tests now as we are running make tests in
CircleCI and I think the base image is shared across Prometheus Org.
Signed-off-by: Goutham Veeramachaneni <cs14btech11014@iith.ac.in>
* Remove Empty Line
Signed-off-by: Goutham Veeramachaneni <cs14btech11014@iith.ac.in>
Due to bad GitHub connectivity, "make" frequently got stuck at the promu
step for me, and I was thinking that "format" was taking a long time
because the promu step wasn't logged. All other Makefile targets have
log statements...
As described in #1898 'go test -race' detects a race in lexer code. This
pacth fixes it and also add '-race' option to test target to prevent
regression.
Simon Pasquier