Automate publishing releases (like packagist with webhooks)

converted markdown lists in initial post to html lists for better readability

added link to missing notes section, that was mentioned in the initial post

A big difference from GitHub & Packagist.org is that Drupal.org releases are permanent. Unlike the other services, we do not allow deleting or replacing releases, so you know you will be able to deploy the same code indefinitely.

We do get occasional support requests for deleting accidental releases, which we do not allow. If everything were more automated, I expect there would be more accidental releases.

That said, we certainly should make some things nicer. For example, if you push a tag which could be a release, we could have links to directly create that release, rather than relying on maintainers to find the place to add a release.

Unlike the other services, we do not allow deleting or replacing releases, so you know you will be able to deploy the same code indefinitely.

Just tested it with git push origin :0.1.2 and broke my complete git access. No git push or git clone to any repo was possible anymore. Logging in and accepting the ToS fixed the broken git access. The error message could have been a bit more elaborative.

git push origin :0.1.2
remote:
remote: ========================================================================
remote:
remote: You (@raffaelj) must accept the Terms of Service in order to perform this action. To accept these terms, please access GitLab from a web browser at https://git.drupalcode.org.
remote:
remote: ========================================================================
remote:
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Good to know.

We do get occasional support requests for deleting accidental releases, which we do not allow. If everything were more automated, I expect there would be more accidental releases.

I get the point. But configuring the webhook is a decision (with somewhat advanced knowledge) to care about git tags and to automate the release process. With some fine tuning, only tags with version strings on branches with version strings could be released automatically.

It doesn't have to be fully automated. Running two different commands would be fine too. Any alternative, that doesn't require logging in and filling out a form (without markdown support and with non-conformant html support) would be great.

git push origin 0.1.3
./deploy.sh
# either with OS key ring integration or
# with manually entering password e. g. via auto type feature from KeePassXC

Besides calling a curl command to trigger a new release, deploy.sh could also contain some logic to parse CHANGELOG.md with the help of md2drupal.sh → . .gitattributes takes care about removing that file from packages/releases.

I use the technique above for a WordPress plugin I maintain to convert git tags to SVN branches.

Just tested it with git push origin :0.1.2 and broke my complete git access. No git push or git clone to any repo was possible anymore. Logging in and accepting the ToS fixed the broken git access. The error message could have been a bit more elaborative.

This one-time ToS agreement is not related to pushing the tag, it was required of everyone: https://www.drupal.org/drupalorg/blog/updating-how-contributors-accept-t... →

The error message is not something that we can configure in GitLab.

Today I found some existing REST API functionality: https://www.drupal.org/drupalorg/docs/apis/rest-and-other-apis →

Only read access is allowed.

So the docs and #2857160: Allow POST via RestWS API → say, that It's read-only. But even if write access was enabled, this wouldn't solve the password management problem (no access token support).

But the api is really interesting for debugging and to get a better understanding of the internal field structure.

Side note: Both api endpoints for a project page contain user ids in the flag_project_star_user field, which should be hidden for privacy reasons:

https://www.drupal.org/api-d7/node/3419729.json →
https://www.drupal.org/api-d7/node.json?field_project_machine_name=theme... →

Access to create release through API has been discussed in Slack in the past.

From memory I believe the biggest hurdle right now is waiting on D.O. to update to D9+ (D10+ now) before it would be considered.

I thought there was a another issue besides #2857160: Allow POST via RestWS API → however it was the only one I could find on my quick search as well.

I probably wouldn't make it an on-commit hook for (most) of my own usage, however I certainly would consider the the possibility of creating a manually executed "publish release" GitLab job that takes a commit ID, runs a final test to ensure the release is passing CI (make sure I don't accidentally publish a broken build), creates the changelog text and than create the release on D.O.

Its certainly been suggested some projects consider more frequent releases and an API would help in that regards (including as far as per commit or per day releases to allow more rapid bugfix adoption)

Even the lack of an API isn't actually as big an issue on this, the bigger issue is the policy against Shared Accounts creating new nodes (releases are a node and my understanding are now allowed to be created by Shared Accounts). I could fairly easily create a script that submits the login form, provides an OTP token and iterates through the release creation steps if that were allowed for a shared account that only has D.O. permissions to manage releases.

I thought there was a another issue besides #2857160: Allow POST via RestWS API → however it was the only one I could find on my quick search as well.

Maybe #3227737: [Meta] GitLab Acceleration Initiative → and #3143620: DrupalSpoons bot → ?

Side note: Both api endpoints for a project page contain user ids in the flag_project_star_user field, which should be hidden for privacy reasons:

Who has starred which project is public information, see https://www.drupal.org/user/3064/starred → . Please report any future privacy concerns directly by emailing security@drupal.org.