trinodb / trino

Official repository of Trino, the distributed SQL query engine for big data, formerly known as PrestoSQL (https://trino.io)
https://trino.io
Apache License 2.0
10.55k stars 3.03k forks source link

trino-docs wont build when your build environment is already inside a docker container #4645

Open dprophet opened 4 years ago

dprophet commented 4 years ago

My build environment is already inside a docker container.

When you run a mvnw build

https://github.com/prestosql/presto/blob/master/presto-docs/build#L11

Tries to run docker run --rm -e PRESTO_VERSION -u 0:0 -v /src/prestosql/build/presto-docs:/docs prestodev/sphinx:2 sphinx-build -j auto -b html -W -d target/doctrees src/main/sphinx target/html

This wont work if the build environment is already containerized (as it should be)

electrum commented 4 years ago

Do the tests work for you, for example, in the presto-mysql module? They also use Docker.

findepi commented 4 years ago

You can use docker in docker, or you can use VMs as a virtualized build environment (as eg GitHub actions do AFAICT). I think e.g. Travis supports both modes.

Using docker during build solves many important problems (python and sphinx local dependencies being one example), and we do not want to go back to these problems. However, you may find this command useful. It skips docs and some other components that do not impact the final deliverable (being the server). It also skips tests (which oftentimes require docker too)

./mvnw -pl '!presto-docs,!presto-proxy,!presto-testing-server-launcher,!presto-verifier,!presto-benchmark-driver' clean install -nsu -DskipTests
dprophet commented 4 years ago

@findepi

I suspect at most large corporations and ALL finance companies, they are not allowed to use external docker containers (sometimes even 3rd party binaries like an RPM). Making various parts of Presto build depend on external docker containers brings up legal issues and breaks the capability to build presto within large corporations.

They must build Presto themselves to remove any legal liabilities that 3rd party will encounter with the use of their 3rd party binaries.

zinking commented 3 years ago

You can use docker in docker, or you can use VMs as a virtualized build environment (as eg GitHub actions do AFAICT). I think e.g. Travis supports both modes.

Using docker during build solves many important problems (python and sphinx local dependencies being one example), and we do not want to go back to these problems. However, you may find this command useful. It skips docs and some other components that do not impact the final deliverable (being the server). It also skips tests (which oftentimes require docker too)

./mvnw -pl '!presto-docs,!presto-proxy,!presto-testing-server-launcher,!presto-verifier,!presto-benchmark-driver' clean install -nsu -DskipTests

I do hope irrelavant ( or stuffs we know will fail such as docker in mac) modules are excluded from the build command to make the build process pass quick and efficiently.

in this case the command didn't work either as modules are renamed ?

findepi commented 3 years ago

@zinking yes, modules got renamed early this year. For current quick build command please refer to https://gist.github.com/findepi/04c96f0f60dcc95329f569bb0c44a0cd which i try to keep up to date. Currently this is:

./mvnw -pl '!:trino-server-rpm,!:trino-docs,!:trino-proxy,!:trino-verifier,!:trino-benchto-benchmarks' clean install -TC2 -nsu -DskipTests -Dmaven.javadoc.skip=true -Dmaven.source.skip=true -Dair.check.skip-all=true?
zinking commented 3 years ago

@zinking yes, modules got renamed early this year. For current quick build command please refer to https://gist.github.com/findepi/04c96f0f60dcc95329f569bb0c44a0cd which i try to keep up to date. Currently this is:

./mvnw -pl '!:trino-server-rpm,!:trino-docs,!:trino-proxy,!:trino-verifier,!:trino-benchto-benchmarks' clean install -TC2 -nsu -DskipTests -Dmaven.javadoc.skip=true -Dmaven.source.skip=true -Dair.check.skip-all=true?

could this be integrated back to Trino main branch, I do believe contributors shouldn't build irrelevant modules when they are developing features and REPL the code. those are usually done after things are finalized, so there should be build aliases to facilitate the development cycle

findepi commented 3 years ago

@zinking we're getting slightly off-topic from the original issue. i suggest we take this question to the #dev slack channel