Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
* Automate publishing.
* Ensure we're tagging releases.
* Consider pre-releases.
* Add gitlab dependency scanning if possible.
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork api_client-3394973
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- ignore-public changes, plain diff MR !79
- final-automation-tweaks changes, plain diff MR !73
- disable-gitlab-releases changes, plain diff MR !70
- ci-ignore changes, plain diff MR !66
- fix-version-command changes, plain diff MR !63
- versioning-fixes changes, plain diff MR !59
- release-bugfixes changes, plain diff MR !56
- adjust-comment-job changes, plain diff MR !53
- release-automation changes, plain diff MR !49
- dependency-scanning changes, plain diff MR !45
Comments
Comment #2
brianperryComment #3
brianperryComment #4
brianperryIt seems like https://www.npmjs.com/package/changesets-gitlab could help simplify the setup here
Comment #5
brianperryComment #7
brianperryOpened 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?
Comment #8
brianperryPicking 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.
Comment #11
brianperryComment #12
brianperryComment #19
brianperryVery 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...
Comment #22
brianperryWe'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.
Comment #24
brianperryThis most recent run succeeded completely hands off, so we can finally close this one :)