Automation Enhancements

It seems like https://www.npmjs.com/package/changesets-gitlab could help simplify the setup here

Opened an MR that adds Gitlab dependency scanning. It doesn't quite do the things I'm expecting. From what I can tell, it won't open PRs to resolve security issues it identifies (but might for some of the paid Gitlab plans?) It also runs a license compatibility report, which adds a bunch of noise we can't act on. Can't find a way to shut that off.

Even with those limitations, some security alerts are better than nothing. For now I restricted it to just prod dependencies.

We'll probably need to do more here. Schedule the dependency scan to run on a regular basis (not just for open PRs?) Implement our own dependabot security MR workflow?

Picking this one up. We have some releasable changes on canary, so now seems like as good a time as any to try to automate our releases.

brianperry → closed merge request !45

brianperry → credited pratik_kamble → .

Very close on the release automation. NPM publishing is working, tags get pushed for the release, but something is happening at the end of the job that Gitlab considers a failure. Will continue debugging on future releases. Might try disabling the tags to see if that eliminates this, but having the tags is nice...

We're really close on this. Currently the automation succeeds for everything we care about (publishing to NPM, pushing tags to the repo) when we merge the 'Version Packages' MR but fails on a final step. Its a little hard to tell from the output, but I think changesets-gitlab is trying to publish gitlab releases and doesn't have permission. I don't think we really need that if the tags are being published, so I'd prefer to skip that step. I've tried setting the `CREATE_GITLAB_RELEASES` variable to false in CI, but that doesn't seem to be doing the trick.

Next steps:
* I'm going to merge a change that uses `INPUT_CREATE_GITLAB_RELEASES` as the variable name just in case that is the issue. The docs are a little unclear on that. It also moves the release job to last in the workflow. The next time we have a release we can see if this fixes it.
* If that doesn't work, we could try bumping up the role or the scopes for the Gitlab token that we're using.

This most recent run succeeded completely hands off, so we can finally close this one :)

Automatically closed - issue fixed for 2 weeks with no activity.