chore: Add workflow to build docker image on branches

[itsoyou]

Build synapse docker images also for branches #2984

My understanding so far is that we only need to generate the base image.
If the PR was generated by org user, the image with tag pr-[pr number] will be available on both ghcr and nexus.
For workflow_dispatch trigger, it requires manual pr_number input.
With current setting, external contributors need approval to run any workflow.
Even their prs got the approval to run the workflow, the write permission is limited and won't able to push the images to any of the registry.
So these workflows are limited to the internal members who have the write permission to our registry.

Need clarification

1. As I mentioned above, the changes in this PR are limited to the internal members who have proper write permission. Would this meet the requirements of this task? or do we need to find a way to give externals the write permission later?
2. Do we also want to build famedly image that contains our modules? what would the expected workflow here?
3. Future improvements:

• we receive pr number as manual input, but later we can do gh search prs --head <branch_name> --json number --state open and retrieve pr number automatically.
• There is no official retention policy to delete old/unused images. Instead we can use this github actions that regularly clean up dev images, but this is not allowed within our org.
• Should we maintaining our own famedly-changes.rst file or something?

Pull Request Checklist

• When opening a PR or pushing to a branch, a container image with a tag named after the branch pr number should be built.
• This should not be abusable by external contributions.
• Require explicit approval to push such nightly images by the matrix team. (current status: Externals can run workflow with approval but can't push images to any registry)
• triggering event should be pull_request, so that random branches from random people won't run our docker build system. Probably should only build the image but not push it for outside contributions.
• Check the authoring user for membership in the organization to use for deciding if 'pushing' the image is required (current status: pr from forks can't run the workflow without permission according to repo settings, so no need to check membership during the workflow)
• The branch image should be accessible in our nexus.
• The branch image should be accessible in ghcr.
• Tag name should include user or organization namespace from the source repo and tag name should include "nightly" or "branch" as a prefix to differentiate them from stable images. The tag will be pr-[pr_number]
• Remember to escape special characters in tag names.
• No git tag versioning for this to prevent confusion with releases.
• The github action for the docker metadata should take care to strip-out/escape incorrect/ineligible characters. Looks like the that same github action has some interesting/useful bits attached to it's ref type filter for the tag name.
• create only amd64 runner

[jason-famedly]

Just a few things, this is looking pretty good

[jason-famedly]

I think this will work just fine. If we need anything changed out later, we can do so then 🚀

[jason-famedly]

Gonna try something, since this was actually pushed to the default branch
fixes famedly/product-management#2984

[itsoyou]

This change has been pushed to master with command git push origin syk/build-docker-image-for-branch:master so I am closing it.
Check commit 894ed2f48e0cbf41246b6bd4c62275ae1632dbb1 on master for detail.

[jason-famedly]

As I mentioned above, the changes in this PR are limited to the internal members who have proper write permission. Would this meet the requirements of this task? or do we need to find a way to give externals the write permission later?

I think it's ok to approve these as we go, if even needed? 🤷‍♂️ Figure this will keep the storage down too. We may want to see what this looks like. If it gives a bunch of notifications or a huge batch of yellow lights, we may revisit this.

Do we also want to build famedly image that contains our modules? what would the expected workflow here?

I think building PR images with the modules generally is not needed. It may depend on who the external contributors are. Are they the customers or just random admins that are using our work and want to give back? That being said, if needed we can probably just edit the existing workflow for our production images to have a smarter trigger, or even adjust the workflow_dispatch in some way to do this.

we receive pr number as manual input, but later we can do gh search prs --head <branch_name> --json number --state open and retrieve pr number automatically.

If you would like to try and experiment to see what that would look like, I'm game to see what it will do. Obviously we can't do it on our local machines(I think we are not allowed to use the cli GH client? I don't remember what they said about that)

There is no official retention policy to delete old/unused images. Instead we can use this github actions that regularly clean up dev images, but this is not allowed within our org.

I think for the moment this is ok to ignore. We would need permission(from either Nico or Niklas) to use a new external workflow.

Should we maintaining our own famedly-changes.rst file o

Nope 😆 Largely we will just use a git log command that will list the changes found between releases and inject that into the existing CHANGES.md file. It may come that we need to do something fancier similar to how upstream does with newsfiles and such that will build a changelog for us