Build and deploy changes

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