[RFC] Build server in CI with optimizations, even in pull requests #3240
Conversation
|
Deploy preview for hasura-docs ready! Built with commit 0fe09cc |
|
Review app for commit a00e338 deployed to Heroku: https://hge-ci-pull-3240.herokuapp.com |
|
I wonder if it would be worthwhile to run the build first with |
|
Don’t you think it’s pretty unlikely that people are going to be pushing code that doesn’t typecheck, anyway? Most of the value of CI is running the full test suite against all the different configurations in parallel, which is difficult to do on one’s workstation. The typechecking shouldn’t be any different in CI than it is on your machine. |
|
Review app for commit 0fe09cc deployed to Heroku: https://hge-ci-pull-3240.herokuapp.com |
|
Review app https://hge-ci-pull-3240.herokuapp.com is deleted |
This PR modifies the CI configuration to always build
graphql-enginewith optimizations enabled, even in pull requests. I think we should do this for the following reasons:Haskell performance without optimizations can be very poor. Doing any performance-related testing against a non-optimized build is not very meaningful, and enabling optimizations could theoretically even make certain tests run faster (even if the compile times are slower).
We push a Docker image with the built server that we encourage users to try, and it’s not good to encourage anyone to ever use non-optimized builds, even if they’re development versions.
If we start doing automated benchmarking in CI, which we plan to, we’ll have to build an optimized version at some point anyway.