This repository was archived by the owner on Dec 11, 2024. It is now read-only.
Do not publish directories with no specs #21
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit ensures that any directories without any specs in them are
not published to Confluence. Prior to this commit these directories
were being published, appearing in Confluence as pages without any
content or subpages. This was distracting when trying to browse the
published specs in Confluence.
One example of this manifesting itself prior to this commit was if the
Gauge concept files were put into their own concepts directory.
As we only publish specs and not concepts to Confluence, having concepts
in their own directory was leading to empty directory pages being
published prior to this commit.
The functional tests implementation code in this commit was lifted and
shifted with only minor alterations from the functional tests repo for
core Gauge (just like the existing functional test implementation
code) - no point in reinventing the wheel.
One other noteworthy thing is that the code to delete a page uses the
low level Go net http client, rather than the higher level
confluence-go-api client. This is because there was a subtle bug
with the confluence-go-api client (it was returning an error even after
a successful delete, despite returning the correct 204 status
code). It may be worth removing the confluence-go-api client
altogether in a future pull request, as minimising dependencies is
generally a good thing.