Stream: committers
Topic: CI Build
Grahame Grieve (Jul 15 2016 at 23:15):
@Josh Mandel we need to change the CI build process now. we need to start building a bunch of implementation guides as well as the main build
Grahame Grieve (Jul 15 2016 at 23:16):
there's some complexities here - the jar to build the IGs with is built by the main build.
Grahame Grieve (Jul 15 2016 at 23:17):
so we take that jar, and use it to build a whole lot of igs, some of which are in github projects, not the main svn repository
Grahame Grieve (Jul 15 2016 at 23:18):
changes to the main mean we need to rebuild all IGs, while changes in the IGS mean we need to rebuild by the dependencies declared in the IGs.
Grahame Grieve (Jul 15 2016 at 23:18):
I don't know whether all that complexity is possible
Josh Mandel (Jul 16 2016 at 17:03):
OK! Is there a script that we should run, to group all of that logic together? (Or a script I should write?)
Grahame Grieve (Jul 16 2016 at 21:09):
we'll have to write one between us
Grahame Grieve (Jul 16 2016 at 21:27):
one tricky question is about the terminology cache
Grahame Grieve (Jul 16 2016 at 21:28):
it makes a massive speed difference, but occasionally has to be cleared out. I've moved it out of version control, into the users local directory, but i'm not sure that's working out
Josh Mandel (Jul 17 2016 at 00:55):
Are you suggesting that we'd trigger re-builds of each IG every time that the main repo changes? That seems... hard. Better, I think, for IGs to live their own separate lives and point to a specific revision of the main build. IG authors can update this explicitly when they're ready, and then their IGs can rebuild. We could provide IG authors a sample travis.yml file they can add to their project, for example.
Lloyd McKenzie (Jul 17 2016 at 02:46):
I think tying IGs to specific versions of the spec is good. The tricky bit is what an IG does if they want to point to a frozen snapshot and have the links work. I suspect we'll say we'll create snapshots for major connectathons or ballots, but other than that, during development, they'll have to live with certain links not working some of the time. Inputs to the build process would presumably be a snapshot of the validation.xml.zip (or whatever it's called now) and the URL where the spec is located?
Grahame Grieve (Jul 17 2016 at 07:32):
I find the idea that IGs would point to specific versions of the spec really difficult indeed.
Grahame Grieve (Jul 17 2016 at 07:33):
right now, the version of the spec is rolling over pretty quickly, and many changes are because of the IGs. Tieing IGs to a specific version of the spec just means that this has to be changed everytime the spec changes - seems like chasing your tail to me
Grahame Grieve (Jul 17 2016 at 07:34):
also, right now, I've unhooked most of the IGs from the main build, and no one is getting notified when they don't build because the profiles need to change. '
Grahame Grieve (Jul 17 2016 at 07:34):
of course, for IGs based on a stable release, that's different
Grahame Grieve (Jul 17 2016 at 07:35):
right now, you build with the IG publisher for a specific build, and it contains all the internal knowledge that it needs. We can only support publication of IGs from supported forks (ones where I can produce an updated IG publisher)
Grahame Grieve (Jul 17 2016 at 07:36):
and right now, the only supported fork is trunk
Grahame Grieve (Jul 17 2016 at 09:03):
and. btw, the principal driver for me is that when I release a new IG publisher, I want to know whether I've broken anything
Grahame Grieve (Jul 17 2016 at 10:08):
at the very least, we can run the test IG build
Last updated: Apr 12 2022 at 19:14 UTC
