- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Wed, 14 Sep 2022 12:43:57 +0100
- To: public-xslt-40@w3.org
- Message-ID: <m2wna65fwf.fsf@Hackmatack-eth.fritz.box>
Hi folks, I think I’ve sorted out how to make formatted versions of specifications automatically for each PR. I’m going to switch from using an external CI environment to using GitHub actions. That means the actions will run in your forks as well as in the qt4cg/qtspecs repository. There are two actions at the moment: build-specs: builds the current specs on any commit to master. build-pr: builds a PR Unless you have pull requests *on your fork*, you’ll never see the second action run on your fork. The first action will run on any commit to master and will “succeed” or “fail” depending on whether the build worked. (If, for example, you commit a markup error, that’ll cause the build to fail.) If you create a ‘gh-pages’ branch in your local fork and set the ACCESS_TOKEN repository secret to a personal access token with write access to your repositories, then the build-specs action will publish your versions to your gh-pages branch. Otherwise, it just reports success or failure in building. The build-pr action is a little more interesting. It will run on the qt4cg/qtspecs repository whenever you create a PR. Any changes you make to XML files (specifications, use cases, etc.) will be reflected in the PR. If you attempt to change any aspect of the build system or the stylesheets, those changes will be ignored. This is necessary to protect the secrets that are necessary to push PRs to the gh-pages branch. If the PR builds successfully, the formatted versions will be published to qt4cg.org/pr/NNN where “NNN” is the PR number. At least, that’s the way it works in my testing! We’re about to find out if it works “in real life”. If you have any questions or problems, let me know. Be seeing you, norm -- Norm Tovey-Walsh Saxonica
Received on Wednesday, 14 September 2022 11:56:00 UTC