Well, the event that triggers it is a new commit being pushed to GitHub.
There's no way to tell what's in the commit without inspecting it. I don't
know if there's a way around that. There is an FSTrigger plugin that
monitors the file system and triggers builds based on changes to particular
files/directories. I suppose you could have a separate process that does
git operations and use that, but setting it up and replicating it might be
a pain.
It doesn't seem backwards at all to me, because we already maintain our
documentation outside the TEI repo for the most part. This would just mean
not putting it in there in the first place...
On Mon, Aug 8, 2016 at 11:06 AM, Lou Burnard
On 08/08/16 15:05, Hugh Cayless wrote:
Kevin has asked that we freeze posting in the CMS until it has been migrated, so I'm behind on posting the minutes with no way to catch up. I'm thinking I may just start a "documentation" repo and put both the minutes and the TCW docs there. I don't really like having documentation in the TEI repo, as updating the docs really shouldn't trigger a Jenkins build.
This seems backwards. I quite agree that updating the docs shouldn't trigger a Jenkins build but is it really the case that the only way to fix that is to move Documentation to an entirely different repo? Surely Mr Jenkins could be persuaded to be a bit more selective about what wakes him up?
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived