Can we move the whole HTML build process to Travis #103
Comments
|
That's probably doable. Currently Travis is only used as a validation step. It uses wattsi-server. Whereas, the build on the actual server uses a local copy of Wattsi. Given that we already use Bikeshed via its web service I guess there's no problem with relying on wattsi-server. |
domenic
added a commit
that referenced
this issue
Aug 18, 2017
This adds a new subdirectory, ci-deploy, with scripts and other resources for building, validating, and deploying the spec entirely on Travis. Previously Travis was only running build and validation steps, but then throwing away the results, letting custom deploy architecture handle the actual deploy. This replaces the custom deploy architecture with something in source control and web-host-agnostic. This deploy is Docker-based, for two main reasons: * It is not easy to install FreePascal 3.x onto Travis CI's default Ubuntu configuration, which is fairly old (even with recent Trusty updates). It is simpler to create a Docker container with a recent OS and install FreePascal 3.x there. * Docker has a good mechanism for caching previous results and not doing unnecessary work until the cache is invalidated. This is important as it allows us to avoid reinstalling prerequisite packages and recompiling Wattsi on every build. Travis CI has some caching support, but it is not as full-featured as Docker's. The intermediate containers created for this caching are stored on Docker Hub; see https://hub.docker.com/r/whatwg/html-deploy. The ci-deploy/README.md file contains more instructions on how this is expected to be used, and will be used by whatwg/html's .travis.yml in whatwg/html#2941. Fixes #11. Fixes #99. Fixes #103.
domenic
added a commit
that referenced
this issue
Aug 18, 2017
This adds a new subdirectory, ci-deploy, with scripts and other resources for building, validating, and deploying the spec entirely on Travis. Previously Travis was only running build and validation steps, but then throwing away the results, letting custom deploy architecture handle the actual deploy. This replaces the custom deploy architecture with something in source control and web-host-agnostic. This deploy is Docker-based, for two main reasons: * It is not easy to install FreePascal 3.x onto Travis CI's default Ubuntu configuration, which is fairly old (even with recent Trusty updates). It is simpler to create a Docker container with a recent OS and install FreePascal 3.x there. * Docker has a good mechanism for caching previous results and not doing unnecessary work until the cache is invalidated. This is important as it allows us to avoid reinstalling prerequisite packages and recompiling Wattsi on every build. Travis CI has some caching support, but it is not as full-featured as Docker's. The intermediate containers created for this caching are stored on Docker Hub; see https://hub.docker.com/r/whatwg/html-deploy. The ci-deploy/README.md file contains more instructions on how this is expected to be used, and will be used by whatwg/html's .travis.yml in whatwg/html#2941. Fixes #11. Fixes #99. Fixes #103.
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've lost track a bit about how the various pieces fit together, but it seems whatwg/html already uses Travis to build the HTML Standard. Why not add some rsync/scp at the end of that and remove all scripts from the server? Having the server just host static resources seems much better.
The text was updated successfully, but these errors were encountered: