Setup publishing workflows

[kprosise]

Workflows set up for next to publish to dev, and main to publish the versioned docs. next will publish when changes are merged, main will publish when a tag is created.

Other changes made to the configuration file for cleanup and removal of variables that complicated workflow enablement, or served no real purpose.

Ran action lint, minor but not breaking issues reported. Tested over multiple commits, before squashing and opening PR.

This commit applies to FFTK-4532, "add dev version" This commit applies to FFTK-4116, "Use GitHub Action…" This commit applies to FFTK-4763, "test workflow…"

PR Template and Checklist

Please complete as much as possible to speed up the reviewing process.
You may delete items that are not relevant to your contribution.
Readiness and adding reviewers as appropriate is required.

All PRs should be reviewed by a technical writer/documentation team and a peer.
If effecting customers—which is a majority of content changes—a member of Customer Success must also review.

Readiness

• Merge (pending reviews)
• Merge after date or event
• Draft

Checklist

• Run spelling and grammar check, preferably with linter.
• Step through instructions (or ask someone to do so).
• Review for wordiness
• Match tone and style of page/section.
• Run make linkcheck, and add redirects for any moved or deleted pages.
• View HTML in a browser to check rendering.
• Use semantic newlines.
• follow best practices for commits.
  • Descriptive title written in the imperative.
  • Include brief overview of QA steps taken.
  • Mention any related issues numbers.
  • End message with sign off/DCO line (-s, --signoff).
  • Sign commit with your gpg key (-S, --gpg-sign).
  • Squash commits if needed.
• Request PR review by a technical writer and at least one peer.

Comments

All work has been tested on next

[doanac]

There's a lot of code that's almost the same. i wonder if they could inherit from a common workflow that was parameterized or something.

However - I also see people go to great lengths to avoid copy/paste where copy/paste would have been a lot easier to deal with in the long run.

I think this is fine to move forward with. I'd actually vote that you eventually take this one step further and move the rest of the remaining docs publishing logic out of lmp-release-tooling and you start handling releases of docs totally from github.

[doanac]

I might change this to be more specific like:

 - mp-*
 - v*

or something

[kprosise]

I was debating that, keeping in mind potential changes in the future, but yeah, that would allow me to keep things simpler too