W3C home > Mailing lists > Public > spec-prod@w3.org > October to December 2014

Re: WebIDL validity in continuous integration

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 14 Nov 2014 08:52:42 -0800
Message-ID: <CAAWBYDCzi7R+Z+X8e6=8tPdXkcH9t7eFnoc6q0iz6usgtFEY=Q@mail.gmail.com>
To: Dominique Hazael-Massieux <dom@w3.org>
Cc: "spec-prod@w3.org Prod" <spec-prod@w3.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Fri, Nov 14, 2014 at 4:45 AM, Dominique Hazael-Massieux <dom@w3.org> 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
Received on Friday, 14 November 2014 16:53:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:42:21 UTC