Document ways for a user to test/run the Arrow collector #72
Comments
jmacd
added a commit
that referenced
this issue
Nov 10, 2023
…, update all READMEs (#92) This PR (at last!) fixes a number of outstanding Golang module issues. We now use a checked-in go.work file. The important aspect of this change, for the go.work approach to work, involves using the OTC `builder` with its `--skip-get-modules` flag set. This allows the go.work file to be used instead, and we now call `go work sync` instead. There are no more `replace` statements in any of the go.mod files, so single-line commands will now work (after the next release). The new BUILDING.md instructions explains how to build either with a local Golang toolchain, or using a Docker Golang toolchain. Each example has been tested and updated for a number of minor changes, including: - batchprocessor -> concurrentbatchprocessor - loggingexporter -> debugexporter - eliminate arrow::disabled flags - consistent port numbering - working `printer` example (now with fewer dependencies) - one fewer examples, there was a little redundancy. Fixes #72. --------- Co-authored-by: Laurent Quérel <laurent.querel@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The user experience for building and running an Arrow collector is currently very opaque.
The problem is exacerbated by
go.modproblems. We are usingreplacestatements in our multi-module repositories to enable development, an old solution to a problem currently addressed bygo.workfiles.We are unsure whether checking-in a go.work file is a good plan, but it would apparently improve the situation.
Beyond cleanups of this sort, we need a page describing how a user can quick-start from a collector build configuration, to an initial yaml file, to first data flow.
The text was updated successfully, but these errors were encountered: