This is one reason why code generation should run as part of the build process, every time. Even if you decide to check-in the generated code for visibility.
> Even if you decide to check-in the generated code for visibility.
I prefer checking it in by default (generated and checked in by users; CI failing if re-generation during the build generates diff).
It enables much simpler debugging collaboration ("do you have diff in the gen/ dir when you try to repro this bug? I don't."), mistaken-checkin prevention ("did you accidentally run protoc on the wrong version before adding files to this commit? CI's failing because it sees changes in gen/ without changes to requirements or .proto files") and easier verification of upgrades just like this one.
With the ability to use .gitattributes to suppress generated diff visibility by default widely supported (if not well-standardized) across Git repo management platforms, the drawbacks of checking in generated sources are minimal.
The internal tools I've used regenerate the code as part of the CI process, and will fail the pipeline if the regenerated code has dirtied the git tree.
zbentley|1 year ago
I prefer checking it in by default (generated and checked in by users; CI failing if re-generation during the build generates diff).
It enables much simpler debugging collaboration ("do you have diff in the gen/ dir when you try to repro this bug? I don't."), mistaken-checkin prevention ("did you accidentally run protoc on the wrong version before adding files to this commit? CI's failing because it sees changes in gen/ without changes to requirements or .proto files") and easier verification of upgrades just like this one.
With the ability to use .gitattributes to suppress generated diff visibility by default widely supported (if not well-standardized) across Git repo management platforms, the drawbacks of checking in generated sources are minimal.
skunkworker|1 year ago
peterldowns|1 year ago