semi-automate the task of updating source/p5subset.xml and reviewing expected results

[peterstadler]

During our last Council conf call on 2020-09-08 we discussed how to automate the (new) task of regularly updating source/p5subset.xml, reviewing, and incorporating the needed changes into the expected results.
Background: the Stylesheets test suit needs a p5subset.xml for testing ODD processing. While formerly this was dynamically pulled from the web, we recently added a dedicated p5subset.xml to the Stylesheets repo to have more control over this source for testing the Stylesheets. Hence we are now in the situation to decide on a policy (not the scope of this ticket ;) and to develop technical means to facilitate these updates (this ticket).

The proposed solution we want to explore is automating the creation of a pull request (triggered by changes to the Guidelines repo) which we then may review.

[hcayless]

I'm a little unclear on precisely what we want to do here. We could have a push to the Guidelines trigger an action that

1. Builds p5subset.xml
2. Checks out the Stylesheets and compares the new p5subset to the one the Stylesheets contains.
3. If they're different, do what? Trigger a pull request for p5subset? Build the examples for the Stylesheets (pretty sure there's a Make target for that) and do a pull request for p5subset and the new examples?

[peterstadler]

@hcayless that (do a pull request for p5subset and the new examples) sounds exactly what I'm looking into. I have a draft build file at my Stylesheets fork where I'm tying to document the process in a way that we could use it a) manually and b) as a job on Jenkins. a) is more or less trivial but nevertheless good to have it formalized, and for b) we need to provide some credentials. I'm thinking of employing our bot user @TEITechnicalCouncil with a constrained access token for only public repos (I think that's the least we have to grant).