9da6fb3410
In the case that there is a read error, we would close the lines channel before sending the error into the read error channel. closing lines then allows the write goroutine to possibly send in a nil error before read is able to, causing the main function driving both to return a nil error. Additionally, it is possible for both reads and writes to race sending errors into their channels, and the main goroutine will only read from one, causing the other goroutine to leak. To fix this, we close lines only after we have sent an error into the channel, we ensure we read from both errors to make sure that both have exited, and we unify the channels and add a buffer of size two to the channel. It is possible for write to exit leaving read blocked forever, but write only exits with a nil error when read has exited, so this only happens during an actual write error, just like before. Channels are hard. |
||
|---|---|---|
| .circleci | ||
| .github | ||
| bolt | ||
| chronograf | ||
| cmd | ||
| context | ||
| docker | ||
| etc | ||
| flux | ||
| gather | ||
| http | ||
| inmem | ||
| internal | ||
| kit | ||
| kv | ||
| logger | ||
| mock | ||
| models | ||
| nats | ||
| pkg | ||
| prometheus | ||
| query | ||
| rand | ||
| scripts | ||
| snowflake | ||
| source | ||
| storage | ||
| task | ||
| telegraf/plugins | ||
| testing | ||
| toml | ||
| tools/tmpl | ||
| tsdb | ||
| ui | ||
| uuid | ||
| vault | ||
| write | ||
| zap | ||
| .gitignore | ||
| .goreleaser.yml | ||
| Jenkinsfile | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| auth.go | ||
| authz.go | ||
| authz_test.go | ||
| bucket.go | ||
| dashboard.go | ||
| dbrp_mapping.go | ||
| dbrp_mapping_internal_test.go | ||
| dbrp_mapping_test.go | ||
| error.go | ||
| errors.go | ||
| errors.md | ||
| errors_test.go | ||
| example_test.go | ||
| go.mod | ||
| go.sum | ||
| id.go | ||
| id_test.go | ||
| keyvalue_log.go | ||
| label.go | ||
| label_test.go | ||
| lookup.go | ||
| macro.go | ||
| macro_test.go | ||
| measurement.go | ||
| onboarding.go | ||
| operation_log.go | ||
| organization.go | ||
| paging.go | ||
| query.go | ||
| scraper.go | ||
| secret.go | ||
| session.go | ||
| source.go | ||
| status.go | ||
| task.go | ||
| telegraf.go | ||
| telegraf_test.go | ||
| token.go | ||
| tools.go | ||
| usage.go | ||
| user.go | ||
| user_resource_mapping.go | ||
| user_resource_mapping_test.go | ||
| view.go | ||
| view_test.go | ||
| write.go | ||
README.md
InfluxData Platform 
This is the monorepo for InfluxData Platform, a.k.a. Influx 2.0 OSS.
Installation
This project requires Go 1.11 and Go module support.
Set GO111MODULE=on or build the project outside of your GOPATH for it to succeed.
If you are getting an error loading module requirements error with bzr executable file not found in $PATH” on make, brew install bazaar (on macOSX) before continuing.
For information about modules, please refer to the wiki.
Introducing Flux
We recently announced Flux, the MIT-licensed data scripting language (and rename for IFQL). The source for Flux is in this repository under query. Learn more about Flux from CTO Paul Dix's presentation.
CI and Static Analysis
CI
All pull requests will run through CI, which is currently hosted by Circle. Community contributors should be able to see the outcome of this process by looking at the checks on their PR. Please fix any issues to ensure a prompt review from members of the team.
The Platform project is used internally in a number of proprietary InfluxData products, and as such, PRs and changes need to be tested internally. This can take some time, and is not really visible to community contributors.
Static Analysis
This project uses the following static analysis tools. Failure during the running of any of these tools results in a failed build. Generally, code must be adjusted to satisfy these tools, though there are exceptions.
- go vet checks for Go code that should be considered incorrect.
- go fmt checks that Go code is correctly formatted.
- go mod tidy ensures that the source code and go.mod agree.
- staticcheck checks for things like: unused code, code that can be simplified, code that is incorrect and code that will have performance issues.
staticcheck
If your PR fails staticcheck it is easy to dig into why it failed, and also to fix the problem.
First, take a look at the error message in Circle under the staticcheck build section, e.g.,
tsdb/tsm1/encoding.gen.go:1445:24: func BooleanValues.assertOrdered is unused (U1000)
tsdb/tsm1/encoding.go:172:7: receiver name should not be an underscore, omit the name if it is unused (ST1006)
Next, go and take a look here for some clarification on the error code that you have received, e.g., U1000.
The docs will tell you what's wrong, and often what you need to do to fix the issue.
Generated Code
Sometimes generated code will contain unused code or occasionally that will fail a different check.
staticcheck allows for entire files to be ignored, though it's not ideal.
A linter directive, in the form of a comment, must be placed within the generated file.
This is problematic because it will be erased if the file is re-generated.
Until a better solution comes about, below is the list of generated files that need an ignores comment.
If you re-generate a file and find that staticcheck has failed, please see this list below for what you need to put back:
| File | Comment |
|---|---|
| query/promql/promql.go | //lint:file-ignore SA6001 Ignore all unused code, it's generated |