Don't hint at support for using an existing Postgres #7
Comments
|
In fact, just fold it into |
LukeShu
added a commit
that referenced
this issue
Sep 6, 2019
This includes several unrelated fixups from getting things ready for <https://github.com/datawire/ambassador-ratelimit/pull/6>. - Expand `build-aux/README.md` - Fix the `make lint` rule for Go - Fix complaints from `make lint` - Fix `go-mod.mk` on macOS - Be a little more robust when setting `go.bins` - CI: Run `make check`
LukeShu
pushed a commit
that referenced
this issue
Sep 9, 2019
Add grpc-web support to the client and simplify grpc support overall
LukeShu
added a commit
that referenced
this issue
Aug 1, 2020
build-aux: migrate to go.mod, rewrite go-opensource in Go This is the upstream PR of <https://github.com/datawire/apro/pull/258>. I did the work downstream in apro.git, so that I could actually tell if things work. # Description ### Rewrite `go-opensource` in Go (issue datawire/build-aux#7) - The `go-opensource` program is slow - The `go-opensource` program is a Bash script that I meant to rewrite in Go for speed and maintainability - The `go-opensource` program creates non-reproducible outputs In datawire/build-aux#7, I mentioned that I'd prefer to do datawire/build-aux#4 (or rather, just the build-aux.git portion of datawire/build-aux#4) first. The reason for that is that I wanted to be able to use external libraries in the Go implementation of `go-mkopensource`, as currently all of the Go programs in build-aux have to be single-file programs that only use the standard library. The Go version still has room for improvement; it's mostly a straight-port of the logic from the Bash version (except that it takes advantage of JSON parsing to call `go list` only once with `-json`, instead of calling it multiple times with different args). It should be taught to look directly in the module cache like `go mod vendor` does, instead of looking in `./vendor/`. It should have better license recognition. Its license-file detection should mimic `go mod vendor`'s. ### Migrate build-aux.git to use `go.mod` instead of `curl` (issue datawire/build-aux#8 within the epic of datawire/build-aux#4) I turned datawire/build-aux#4 in to an epic, and added datawire/build-aux#8 as the build-aux.git portion of it. Part of that is migrating the stuff in build-aux to use compiled binaries instead of `go run`. In order to avoid things getting too messy, I moved executables to be in `./build-aux/bin/` instead of directly in `./build-aux/`. That's a breaking change for users of build-aux. However, I also made sure that every program in `./build-aux/bin/` has a variable that refers to it, so build-aux users can just use the variable, instead of actually caring about the location. That doesn't help with this breakage though, as a few programs, like `tap-driver` didn't have a variable before now. # Other - [X] DONE: Created `CHANGELOG.md` - [x] DONE: "Some of what's in the commit messages probably belong in "the docs" somewhere, e.g. the description of what an Executable output is." - [X] DONE: Resolve conflicts between the migration go `go.mod` and the `make go-doc` changes. - [X] DONE: Adjust `build-aux-push` to not do the thing that resulted in proprietary Go code getting pushed to build-aux.git the first time I tried to push this. Closes #7. Closes #8.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Always deploy
ambassador-storeinstead, which will be used only for us.Later we'll very likely be changing the storage model, so, better to isolate it.
The text was updated successfully, but these errors were encountered: