Automate the packaging of Matomo beta/rc/stable releases via Github actions

[mattab]

To build a release we usually follow these steps:

• create new Github release (which automatically creates a tag)
• run ./scripts/build-package.sh 4.0.0-b3
• the release is signed with my key so it asks for passphrase
• build finishes with success or error

Eventually, there's no way around it: we will need to automate the build of Matomo releases. It would be fantastic if this was completely automated for example via Github actions. I was thinking we could create a new repo for example matomo-releases or so, that only release managers would have access to (Matt, Thomas, Stefan, etc.). Then the Github actions would run in this repo and automate the steps above. We'd need to create a new public/private key pair to sign the build, that only release managers would have access to (and the Github action also).

This would help a lot to let the team release versions without my involvement. And to save me some time. cc @tsteur @sgiehl

[sgiehl]

We could even fully automate that with a github action in the matomo repo. Whenever a tag (or github release) is created we could run the action to build the package. Upload the package to the build server and maybe even add it as release package to the version on github.

If we want to limit that to specific people, we can check if the release was created by someone in a specified list or so... But doing that in another repo would also be possible

[mattab]

fyi @sgiehl adding this to the current milestone, after our discussion

[sgiehl]

I've started setting up an automated build process in my fork. The action yml can be found here: https://github.com/sgiehl/matomo/blob/4.x-dev/.github/workflows/release.yml

It's currently doing those steps:

• The action can be triggered in the actions tab
  • An optional version can be given when triggering the action
• First the action checks if the user is within a certain team (currently it checks if the user is in matomo-org/core-team). Later we could create a new team release-managers or similar, so we are able to limit the access to this action
• If no version was provided when triggering the action the version is taken from Version.php and the action tries to create a new tag for that. If a tag already exists the action will fail
• If a version was provided, the script checks that this tag already exists. Otherwise it fails
• The matomo-package repo will now be checked out and the build-package.sh will be executed with the version
• Afterwards the ncipollo/release-action action is used to create a new release in the repo. The matomo archives, that were created with the build script, will be attached to the release. See e.g. https://github.com/sgiehl/matomo/releases/tag/4.3.0-b3

The action currently uses a private gpg key, provided as repo secret, for generating the signatures.

Uploading the files to the matomo server currently fails due to the missing ssh access.

@mattab @tsteur Is there anything you would change in that process? Not sure if we should give an github action ssh access to upload the files to the server? We could also upload using FTP or by posting the files to a script on the server or something similar.

[tsteur]

@sgiehl ideally it would be triggered automatically when we tag a release in github? Not sure though if we can restrict who can tag a release or who can trigger a certain action?

Regarding upload to server SSH be likely better than FTP. Posting a release not sure unless it's super crazy secure which may be hard because then you suddenly need to think about brute force etc.

[sgiehl]

@tsteur Can also change the script so it's triggered when a tag is added. The current solution makes it possible to re-release an existing tag, without removing it. But can also allow both triggers. I assume anyone with write access is able to create a new tag. But restricting the action is currently done this way:

First the action checks if the user is within a certain team (currently it checks if the user is in matomo-org/core-team). Later we could create a new team release-managers or similar, so we are able to limit the access to this action

Do we have a server when I can test some ssh uploads?

[tsteur]

Sounds good to use an action then so this way we can restrict it better. The action would create the tag then.

I created an account on our matomo server. You can connect using ssh innocraft-staff-stefan@matomo.org using your SSH key. Let me know if you need anything else 👍