Almost auto releases

[potatoqualitee]

I've created a workflow on my own personal repository that automates releases. I kept it on my own repo because the secrets are super secret and I want to be the only person with access to them (tho other maintainers have the cert)

Here's what it does:

• Checks to see if any PRs have been merged since last release. If so, then it continues on to the next step.
• Clones dbatools repo using gh
• Downloads and caches helpout, a module by @StartAutomating that we use to build our help files and create allcommands.ps1
• Bumps up the module version by 0.0.1 (ht @SQLDBAWithABeard for the non-destructive replace)
• Rebuilds the json file with all of our command info for both Find-DbaCommand and docs.dbatools.io
• Downloads the latest Glenn Berry scripts
• Preps the module for the gallery and signs it using our Code Signing Cert that @sql-williamd and @eelcodrost have graciously provided us
• Publishes to the PowerShell Gallery
• Commits the changed files (psd1, glennberry, json file, etc) to development
• Merges dev to master
• Creates a GitHub release based on master using the version number and auto generates the changed info using PR info, including author, so we should keep our PR titles tight
• Tags the branch
• Rebuilds the docs website using @niphlod's awesome builder

I have the code commented out that schedules this nightly (it would skip if no PRs have been merged) because I'd still like to review every commit prior to release because I think it's the right thing to do, even though very few of us (@potatoqualitee, @niphlod, @jpomfret, @Stuart-Moore, @SQLDBAWithABeard, @wsmelton and @FriedrichWeinmann) have merge privs.

🥳 🚀

[SQLDBAWithABeard]

Thats absolutely awesome and fantastic and I LOVE it.

• If the PR has been approved and merged, is that good enough? Who can approve PRs?

Second. I am working on a process for deployment of the Chocalatey module https://github.com/SQLDBAWithABeard/Chocolatey/tree/main
using Sampler https://github.com/gaelcolas/Sampler which is comparable to this. https://www.youtube.com/watch?v=UWGKgVB4VNU&t=460s

Everything is controlled by the build.ps1 and the build.yaml using the tasks from the module or included from dependant modules.

Not saying it should be used here but thought you may be interested as it is along the same lines

[wsmelton]

As well, this configuration would have to change to start using Code Owners

[SQLDBAWithABeard]

Which way do you think is best?

With code owners you can set certain people for certain areas which may be useful?

[wsmelton]

All depends on whether we are going to auto-merge pull request when they have approvals. As-is right now, it would require approval from a maintainer to auto-merge something onto Dev.

[SQLDBAWithABeard]

So is that the point where there is validation and protection? As it is right now without any changes?

What do you think would improve the cadence, keep it safe, and reduce the manual input?

Is having that automation workflow good enough?

I am just asking the questions :-) I dont know the answers particularly

[potatoqualitee]

OH YEAH! I forgot that about the Approvers! The Internet had a good chuckle with this PR, titled "Throw this whole thing in the trash " and it was approved by everyone.

[SQLDBAWithABeard]

Its literally only because I am working and using that code that I came to use it myself so I know what you mean!!

OK - PRs merge to develop. You could set that workflow and have it run on merge to master which could only be done by admins if you set the security?

Or, leave it as it is because it takes the pain out of you having to manually do things 👯‍♀️ .

What is the aim?, because that is awesome and automation is royalty. (We still need to ensure that there is some validation by a human bean of course)

[wsmelton]

Correct, our master branch is protected so only those with Maintainer rights on the repository would be able to merge.

[potatoqualitee]

You could set that workflow and have it run on merge to master which could only be done by admins if you set the security?

That was my first thought/method and even used a really awesome action peter-evans/repository-dispatch@v1, but the problem is that we merge to dev, then master would get the updated version, then it'd have to come back down to dev.

I could have even limited it to potatoqualitee being the merger, but it just didn't feel right until I did it this way, which mimics the manual publish process I follow on my laptop. The other thing was that we build docs from master, and it just got complicated.

The ultimate goal was to have a one-liner (gh workflow run dbatools.yml) against a remote repo where only I can decrypt the tokens and basically have github do what I did manually. Changing the version, signing, encoding, etc. So it's just my process done by GitHub.

The gh CLI has been awesomeeeee for this!