On feature branches and pull requests the specs are published to the
test Confluence instance, then on every push to master they are
also published to the production Confluence instance as well as to the
test instance (no harm in publishing to test from master too, as if
the publishing to production ever fails for some reason it will provide
a useful comparison).
The pipeline code is in two separate workflow files, one for publishing
to the test Confluence instance and one to the production instance.
This has the downside of duplication, but the important upside of using
GitHub's environment protection rules to give additional
protection against publishing to the production instance from a feature
branch. The duplication is not large (and is only in two places),
so the upside outweighs the downside.
This commit publishes the plugin's actual Gauge specs so that they can be viewed on Confluence as living documentation.
Unfortunately the Confluence Space with the published specs cannot currently be opened up for public access, as Confluence do not allow anonymous access on their free plan.
On feature branches and pull requests the specs are published to the test Confluence instance, then on every push to
master
they are also published to the production Confluence instance as well as to the test instance (no harm in publishing to test frommaster
too, as if the publishing to production ever fails for some reason it will provide a useful comparison).The pipeline code is in two separate workflow files, one for publishing to the test Confluence instance and one to the production instance. This has the downside of duplication, but the important upside of using GitHub's environment protection rules to give additional protection against publishing to the production instance from a feature branch. The duplication is not large (and is only in two places), so the upside outweighs the downside.