Testing versioning support

[eldonquijote]

Purpose / why

#265 suggests to find a solution for versioning documentation on the gh-pages branch. This PR models how deployment of versioned documentation could work.

What changes were made?

• Defines a Github Action for deploying documentation upon push to main branch
• Deployment uses Mike for managing multiple versions of documentation (https://github.com/jimporter/mike)
• Following setup guidelines provided in MkDocs Material theme documentation: https://squidfunk.github.io/mkdocs-material/setup/setting-up-versioning/
• Test setup deploys to versioning-test branch, leaving gh-pages and Travis CI configuration alone.
• This setup does not track releases/tags, but always deploys to 2.0.0 subdirectory, unless Github Action is changed manually.

Verification

• Tested with fork of documentation in https://github.com/eldonquijote/documentation, published to https://eldonquijote.github.io/documentation/.
• Might need own fork for testing the deployment to remote versioning-test branch.

Interested Parties

@Islandora/documentation

---

Checklist

Pull-request reviewer should ensure the following

• Does this PR link to related issues?
• Does the proposed documentation align with the Islandora Documentation Style Guide?
• Are the changes accurate, useful, free of typos, etc?
• Does this PR update the last updated on date on the documentation page?

Person merging should ensure the following

• Does mkdocs still build successfully? (This is indicated by TravisCI passing. To test locally, and see warnings, see How To Build Documentation.)
• If pages are renamed or removed, have all internal links to those pages been fixed?
• If pages are added, have they been linked to or placed in the menu?
• Did the PR receive at least one approval from a committer, and all issues raised have been addressed?

[rosiel]

This works! What are the adaptations before we could commit it?

One small suggestion: we could version it as 2.0 instead of 2.0.0 to follow the mike guidelines of dropping the patch number.

[eldonquijote]

@rosiel As far as I can tell, for testing there shouldn't be any adaptations necessary, because it doesn't touch the Travis config and the gh-pages branch that Travis is creating. I would however prefer some sign-off by someone with experience with Github Actions and Travis, to make sure that there are indeed no unwanted interactions.

As for the version number, I'm fine using 2.0 instead of 2.0.0, that's just a matter of changing the Github Actions workflow definition.

[rosiel]

So, I'm confused. Will this cause a new branch to be created (and used) on a permanent basis? Do we need the gh-pages branch too?

[rosiel]

Also, does this mean we're doing Travis and Github actions? Is this a thing that could be combined into just using github actions? Not that it needs to be part of this PR, just trying to see the bigger management picture before we have branches that we're not sure if we can touch.

[eldonquijote]

Yes, in the future there should be only one CI/CD tool, Travis or Github Actions, and only one branch to hold the rendered documents. But I want to test first if this works on this repository, with the permissions that we (I) have to configure things, and using the Materials for MkDocs Insider version that Danny forked for us (which we need to update, but that's another issue).

[rosiel]

I'm good to go for it!

[DonRichards]

@eldonquijote I was wondering where this is at? Is this complete and waiting on a reviewer?

[eldonquijote]

@DonRichards This is ready to go, but I've so far held off because we are not sure anymore if versioning the documentation is practical given that different modules we provide each move at their own pace. We might want to separate the question of versioning the docs from the switch to Github Actions (cf. #1914)

[DonRichards]

@eldonquijote Can we link the docs to a version "tag"? I would like us to move forwards and revisiti if possible. The Sprint is coming up and would like this to be in place to some degree.

[eldonquijote]

@DonRichards Do you mean a version tag for the documentation, or the most current tag of the islandora module? The way I had set it up at one point requires to manually set a version number with the deploy command that the GitHub Action executes. But that was before the switch to semantic versioning and the decision to drop a version number for the stack as a whole.

[DonRichards]

I was thinking either added the semantic version (if not already there) or add a normal tag. But I am finding it difficult this morning to wrap my head around the difference. lol