cq-usecases
cq-usecases copied to clipboard
WICG
Autogenerate index.html
We need to find a way of having TravisCI autogenerating the spec. We shouldn't be seeing the generated version as part of a pull request. If generation fails, then it means something is wrong with the spec.
Maybe there is some guidance over in the BikeShed repo about this? Let's ping Tab if we don't find anything there.
@marcoscaceres Sounds great, thank you.
@hereinthehive @tomhodgins, assigning this to you to investigate.
I'm not sure how to set this up to autobuild on commit in Github. Would that mean we would also be ignoring the HTML file so we could rebuild our own HTML as we edit, and then commit only the BS file to the repository?
Editing a Bikeshed document means rebuilding it a lot while working on it to try to get rid of those error messages, it can be a little picky at times.
Does anybody have more general experience setting up some kind of a build step after commit on Github we could adapt to Bikeshed?
@tomhodgins I've only ever done this using NPM scripts...fairly sure I have!
Hey, so I poked around some of the other repos and found one that solves it:
https://github.com/WICG/picture-in-picture
We need to steal their bash script and travis file (and I guess encrypt credentials so that git merge and push can happen back to the gh-pages branch). Effectively, we would go back to using a "master" branch, and auto-publish to the gh-pages branch.
Anyone feeling brave want to take this on?
At-mention me if you want me to pay attention to a thread. ^_^
Yeah, @domenic has a good auto-deploy-from-Travis script setup for the WHATWG specs; I haven't copied it into the Bikeshed docs yet because I keep forgetting where it is. Maybe he can enlighten us. ^_^
https://github.com/whatwg/whatwg.org/blob/master/resources.whatwg.org/build/deploy.sh is our very comprehensive WHATWG spec build script, including e.g. HTML checking, linting, checking for errors/warnings before running the actual thing, generating commit snapshots separately from living standards, generating a service worker, ... Notably it doesn't upload to gh-pages.
Probably good enough for most purposes is my Travis-CI focused gist: https://gist.github.com/domenic/ec8b0fc8ab45f39403dd
Although https://docs.travis-ci.com/user/deployment/pages/ seems new and perhaps much easier.
@domenic, thanks heaps! @tabatkins, we didn't want to bother you unless we got really stuck.
In any case, working out a generalized solution for this would be quite helpful (and adding that somewhere to BS's docs).. sounds like we are close to that with @domenic's script.
So using deploy, looks like we would just run BikeShed as one would locally. That should be fairly straight forward. We probably don't need any additional scripts unless we want to do additional linting, etc., which I don't think we need for this doc.
@tomhodgins @hereinthehive Does https://github.com/WICG/cq-usecases/issues/59#issuecomment-364328947 provide a bit of guidance/assistance?
Any progress on this, anybody? I was surprised to see today that https://github.com/WICG/cq-usecases/pull/64 wasn’t reflected in https://wicg.github.io/cq-usecases/
@tomhodgins @hereinthehive Have either of you gotten a chance to work on this?
Ah thanks! I just got a new computer yesterday so I can look into this stuff again now :D