Document using base box and dev branch on the playbook instructions.

[rosiel]

Purpose / why

It's not actually documented

• that the islandora playbook's dev branch now defaults to the pre-built base box.
• that the islandora playbook only spins up latest code if you're on the dev branch AND you change the base box.

Note: i think it gets a little long; do you think it should be less verbose? I want it to be simple for people to test PRs, especially, and that means successfully provisioning dev.

in part, this documents #179, and extends the documentation on the dev branch added in #180 to the "official" documentation.

What changes were made?

Reorganized a little of the installation section for clarity.

Verification

Try it? Ideally... i'm not sure if the pre-built box, which doesn't use ansible, can be launched with the vagrant file if you dont have ansible installed.

There are a number of things that seem illogical when written out.

• since 'main' is the branch that is pinned to the most recent release, and 'dev' is the branch focused on getting a bleeding edge environment, the fact that dev defaults to the quick and easy evaluation base box while main uses the really long ansible provisioning, it seems a little backwards to me. I am having a hard time in this documentation describing when you would want to use the 'main" branch vs the 'dev' branch.
• There was a section under the CentOS instructions that included something about vb-guest additions. I'm not sure if it means "if you are on a centos host you need to do this" or "if you want to spin up a centos guest you need to do this." Or both?

Interested Parties

@daniel-dgi

---

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?

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?

[manez]

Wrong Danny tagged, I think. The current is @dannylamb

[manez]

I tried out the instructions and found them easy to follow (and clear about why you'd use dev and a different base box), but I came into it kinda aware, so I'd like to get some fresher eyes on it. Flagging this as maybe something we can ask User Call people to have a look at/run through?

Also, there's some oddness going on with branches and extra commits getting pulled in, but presumably @dannylamb can comment on that alongside whatever else needs to happen to get our branches back in order.

[rosiel]

Git-fu accomplished; main is up to date, and this pr is now current to main. One file changed!
@Islandora/8-x-committers - please read and review the changes!

[dannylamb]

Looks good to me @rosiel. I don't think there's anything left to do here due to the master/main renaming.