add clean kwarg to doc builds

[Ch3LL]

When building the docs locally for development I dont always want to clean out the directory, to ensure consecutive builds are quicker.

[s0undt3ch]

We also have to update the pipeline libs as we merge this.
@bryceml should we start running doc builds in a container on GH Actions?

[bryceml]

We also have to update the pipeline libs as we merge this.
@bryceml should we start running doc builds in a container on GH Actions?

I'd be cool with that if the core team is. The only downside is you can't just go to jenkins and see "all green" in one place. We're supposed to get labhub going this release cycle anyway though, so we could do it on gitlab. Things would be more all in once place if we did that since the tiamat pr builds will be in gitlab.

If it's all done in a container, it's trivial to move between github actions and gitlab though.

[Ch3LL]

im okay with whatever is easiest for you to manage @bryceml and easy for us to see at the same time. Is this decision blocking from having this approved to be merged?

[bryceml]

no, that's not blocking this, this looks good to me.

[bryceml]

This needs merged directly after saltstack/salt-jenkins-pipeline-libs#35

do we want to time that? is there a cleaner path than interrupting all old prs and needing to update branch everywhere?

can we add the ability to call it both ways for a while until all prs get caught up?

@Ch3LL thoughts?

Another option is to leave this pr as is and let the pipeline figure out which one to run.

[bryceml]

something like this maybe? saltstack/salt-jenkins-pipeline-libs#42

[bryceml]

we could also bump the library version for this, that's probably the cleanest way actually.

[Ch3LL]

We can wait to merge this if its going to cause people to rebase. This is just a nice to have, but yeah whichever approach works for me.

[bryceml]

There should be no issue getting this into Magnesium, but it would be fine going into Aluminum too.