Automation

[jamesscottbrown]

This PR should resolve #114 and #119.

When a PR is created against master, this:

• builds a PDF of the spec, and uploads a zip archive of this as a build artefact
• builds the samplers, and uploads a zip archive of these as a build artefact
• create separate zip files containing SVG/PNG/PDF files of each glyph, and upload these as build artefacts

(See examples from a previous run)

When a push to master happens (including when a PR is merged), it also:

• commits the sampler/ directory (containing the automatically generated images). This means the website will be able to link to the image files in GitHub directly.
• updates SEPs/sumamry.csv, and commits the modified file

I think the build artifacts might only be available on GitHub for a limited time, so the PDF/PNG/SVG zip files should be copied to the SBOL website (they could be automatically copied to online storage e.g. by uploading them to an S3 bucket or scping them to a server).

(I suggest closing this PR with squash and merge, as there are lots of trivial commits from trying to get this working that will clutter up the history.)

This also records the version history in the file listing the glyphs, so that the autogenerated .tex files in specification/glyphscript do not need manual modification to add macros like \twotwozeronopage.

[jakebeal]

Looking at the artifacts, I notice a couple of minor issues:

• In the sampler, the "Functional Components" collection should be called "Sequence Features" and the "Species" collection should be called "Molecular Species"
• Since the glyph zip collection is flat, glyphs with the same name (e.g., no-glyph-assigned) collide with one another. That's not necessarily a problem right now, since I think all such cases happen to be identical, but should we nest the collection or generate warnings or something?

[jamesscottbrown]

In the sampler, the "Functional Components" collection should be called "Sequence Features" and the "Species" collection should be called "Molecular Species"

I've modified glyph_list.json to update these names.

Since the glyph zip collection is flat, glyphs with the same name (e.g., no-glyph-assigned) collide with one another. That's not necessarily a problem right now, since I think all such cases happen to be identical, but should we nest the collection or generate warnings or something?

I've added a warning in these cases.