@bmispelon This is not a direct review for this PR, but I have a question:

How do we feel about making this configurable? We can add a workflow_dispatch trigger, and the person doing the deployment can select which branch they need to be dockerized. This could only need a couple of lines of change in the action (I need to check how it affects the deployment script but I don't expect a huge change), and I'm willing to help with that. Having a "branch" input in the workflow will remove the need to have a specific branch for preview/test deployments.

How do we feel about making this configurable? We can add a workflow_dispatch trigger, [...]

That would work too I guess.

• How would the configuration look like? A drop-down where I can pick a branch, or would I have to copy/paste the branch name manually?
• Would this action publish a preview tag any time it's run, or would it tag with a commit id instead (which I'd then need to copy in order to tell the deploy script which tag to use)?
• Having a dedicated preview branch has the advantage that it's easier to know what is actually deployed on the preview server
• Similarly, a preview branch could serve as an integration branch for separate PRs, rather than having to create ad-hoc integration branch when we want to test multiple things at once.

My strategy with this proposal was to do the simplest thing that works. A preview branch is really close to the existing infrastructure and so will require minimal changes (both to this project's github actions and to the deploy playbooks). We can always iterate on it in the future (if we're to have an auto-deploy of some kind for example, then a workflow_trigger style of deployment could be great).

I've also created to do the same for Trac: django/code.djangoproject.com#270

How would the configuration look like? A drop-down where I can pick a branch, or would I have to copy/paste the branch name manually?

This screenshot is from a project that we use a workflow_dispatch trigger for the preview/test deployments. Branch dropdown is provided by Actions and you can add other dropdown or text input fields.

https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_dispatchinputs

Would this action publish a preview tag any time it's run, or would it tag with a commit id instead (which I'd then need to copy in order to tell the deploy script which tag to use)?

It depends. We can tag it as "preview" and instruct the deployment script to use the latest preview image, or tag it with the commit hash and copy the commit hash to the deployment script. However, in my ideal scenario, this trigger would also handle the triggering of deployment, eliminating the need to call the deployment script separately.

Having a dedicated preview branch has the advantage that it's easier to know what is actually deployed on the preview server

Logs of the workflow runs could provide this information if the deployment was integrated. I see the current implementation and the need, and this is the easier solution, but there is also room for improvement. Another common thing I do in the projects I work is creating an admin-only "version" endpoint that returns the current git ref (commit hash + branch/tag name).

Similarly, a preview branch could serve as an integration branch for separate PRs, rather than having to create ad-hoc integration branch when we want to test multiple things at once.

I don't want to trigger another "this was the case in past but we can/should do better" discussion, so I'll keep it short: It makes sense, but it feels like a workaround. I guess I have to agree with it as the short-term solution, but there is room for improvement.

My strategy with this proposal was to do the simplest thing that works ... We can always iterate on it in the future

💯