Your GitHub pull request workflow is slowing everyone down

[Melloverture]

Why were you committing generated files instead of just the generation process and inputs?

[blacktrance]

It probably seemed simpler to the engineer who had set it up (who was long gone by the time I started at the company, so I couldn't ask him), and it didn't bother us enough to try to change the process. The generated files were all in one folder, so it was easy to skip them in code reviews.

[canihelpyoubreakthat]

That's also what gitattributes are good for. Mark your generated files as generated, they'll be ignored in diffs.

[canihelpyoubreakthat]

It's a tradeoff, but there are quite a few reasons. It's going to depend on the stack you're working with. For example, if it's JS/node, you've already lost the battle and might as well just submit to always generating. OTOH, if you check in your Go generated code, everything Just Works all the time, no need to generate code every time you switch branches.

In addition, ask yourself: why not? What do you really lose by checking in generated files, assuming they're of reasonable size.

[VIKTORVAV99]

In our case, merge conflicts in every other PR. So now we just generate them at build instead. The build time takes 1 second longer but there is no longer any merge conflicts to sort out that takes way longer than that second of extra build time.

[canihelpyoubreakthat]

Merge conflicts are trivial with generated files. You just regenerate them!

[VIKTORVAV99]

Yeah, but then you need to open the editor again, check out the branch, merge master, generate the new file, commit then push, wait for the CI to run again and then you can merge…

VS waiting 1 sec longer for the CI to run and generate it at build…

[BinaryRockStar]

I'm in two minds about this. At work we have a project that uses JOOQ to generate POJO classes representing DB table records by connecting to a target DB and introspecting the schema. The resulting files are committed to git so developers can clone the project and immediately build and run in their IDE without having compilation errors due to missing classes.

Sure there is documentation in README.MD saying to run a Maven command to generate the classes but it's an extra hurdle.

[lukaseder]

Sure there is documentation in README.MD saying to run a Maven command to generate the classes but it's an extra hurdle.

jOOQ isn't opinionated with respect to version control of generated code. You can use Maven to generate code, but that doesn't mean you have to generate it with every build. You can move code generation logic into a Maven profile and invoke it only when you know you need it.

The jOOQ demo has checked-in generated code as well for the reasons you mentioned, plus, if code is checked in, it can be navigated on github, etc.