WIP DONOTREVIEW remove generated GraphQL schema.go and DB migrations bindata.go from source control
Created by: sqs
- The schema.go file is auto-generated from schema.graphql.
- The bindata.go file is auto-generated from
migrations/*.sql
.
Pros of not tracking in source control:
- Tracking schema.go in source control means that any GraphQL schema changes have 2 duplicate textual diffs to review.
- Tracking these files in source control mean that any merge conflicts occur 2x and require non-obvious conflict resolution steps (eg
rm migrations/bindata.go && go generate ./migrations
). - This change is consistent with how we handle frontend assets, which are not tracked in source control.
Cons of not tracking in source control:
- It is possible that the codegen tools behave different on CI vs. dev laptops. We lose an extra check against this. In practice, these codegen tools are very simple--they just write a file to a Go string or data structure--and we have not experienced this problem for frontend assets, which are not checked in.
- You must run the build script (
start.sh
or manuallygo generate
) to build the Go code, even if you haven't made any changes. This is already necessary for theweb/
code.
There is another kind of codegenned file that I believe should remain tracked in source control: the schema/*.go
files that hold the Go types generated from the JSON Schema definitions. It is valuable to have these checked into source control because the Go code in those files is human-readable and not just purely duplicative of other files.