WebIDL validity in continuous integration

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

WebIDL validity in continuous integration

Dominique Hazael-Massieux-2
Hi,

As alluded to a week ago on spec-prod [1], I've been looking at setting up
one of my Working Groups with continuous integration tooling to ensure the
specs we develop (and the contributions that are made to it via pull
requests) match continuously a number of quality criteria.

In particular, I now have a Travis CI set up [2] that makes it easy to
check that any commits made to the ReSpec-based WebRTC spec, as well as
any pull requests brought to its repo, keep the WebIDL fragments in it
valid. I'll be expanding that set up to other Github repos of my groups in
the coming weeks.

WebIDL validation is done via the WebIDL checker, a tool that I maintain
separately [3].

Adapting it to non-ReSpec based specs should be fairly simple, and I'm
happy to assist any groups that would like to set this up for their github
repo.

Dom

1. http://lists.w3.org/Archives/Public/spec-prod/2014OctDec/0067.html
2. https://github.com/w3c/webrtc-pc/blob/master/.travis.yml
3. https://github.com/dontcallmedom/webidl-checker/


Reply | Threaded
Open this post in threaded view
|

Re: WebIDL validity in continuous integration

Tab Atkins Jr.
On Fri, Nov 14, 2014 at 4:45 AM, Dominique Hazael-Massieux <[hidden email]> wrote:

> Hi,
>
> As alluded to a week ago on spec-prod [1], I've been looking at setting up
> one of my Working Groups with continuous integration tooling to ensure the
> specs we develop (and the contributions that are made to it via pull
> requests) match continuously a number of quality criteria.
>
> In particular, I now have a Travis CI set up [2] that makes it easy to
> check that any commits made to the ReSpec-based WebRTC spec, as well as
> any pull requests brought to its repo, keep the WebIDL fragments in it
> valid. I'll be expanding that set up to other Github repos of my groups in
> the coming weeks.
>
> WebIDL validation is done via the WebIDL checker, a tool that I maintain
> separately [3].
>
> Adapting it to non-ReSpec based specs should be fairly simple, and I'm
> happy to assist any groups that would like to set this up for their github
> repo.

FWIW, Bikeshed parses and validates WebIDL automatically, so
Bikeshedded specs can't contain IDL errors unless you're deliberating
ignoring the build failures (or have deliberately suppressed its
parsing).  Anyone not using ReSpec or Bikeshed should seriously get
with the program. ^_^

~TJ