feat: add digital-alnd-python feature branch option to publish workflow

[tombrooks248]

What type of PR is this? (check all applicable)

• Refactor
• Feature
• Bug Fix
• Optimization
• Documentation Update

Description

Add a 3rd user input option to the publish workflow in this repo (collection-task) for putting in a feature branch of digital-land-python.

Add a safeguard to prevent people published feature branches to Production.

Why

Currently in order to test some pipeline change in digital land python, in DEV or STAGING you need to create a PR in this repo (collection-task) which points the docker build for the task at your branch in digital-land-python this is annoying and complicated - this change will simplfy that process.

Related Tickets & Documents

• Ticket Link
• Related Issue #
• Closes #

QA Instructions, Screenshots, Recordings

Locally I have run some tests on the logic:

Test 1 — requirements.txt ref rewrite (sed)

Verifies that the Dockerfile's sed rewrites the digital-land-python dependency line to the requested ref, across the ref shapes we expect to use.

ref (build-arg)	shape	result after rewrite	outcome
main (default)	branch	-e git+https://github.com/digital-land/pipeline.git@main#egg=digital-land	no-op, line unchanged ✅
feat/add-expectations-logging	slash branch	-e git+https://github.com/digital-land/pipeline.git@feat/add-expectations-logging#egg=digital-land	rewritten correctly ✅
162-add-data-command-1	branch	-e git+https://github.com/digital-land/pipeline.git@162-add-data-command-1#egg=digital-land	rewritten correctly ✅

Test 2 — "Block feature refs in production" guard

Verifies the guard step's condition (publish.yml) blocks non-main refs from reaching production while leaving every other case free to build.

ref	environment	outcome	why
main (default)	production	ALLOW ✅	normal prod deploy must still work
main	staging	ALLOW ✅	normal staging deploy
feat/add-expectations-logging	staging	ALLOW ✅	the feature — test an unmerged branch in staging
feat/add-expectations-logging	production	BLOCK ✅	the safety net — feature refs never reach prod
162-add-data-command-1	production	BLOCK ✅	same, for a non-slash branch name

All cases behave as intended: the guard only fires on the single dangerous combination (non-main ref and production), and the normal main-to-production path is unaffected.

Test 3 — End-to-end Docker build (local)

Proves the digital_land_python_ref build-arg flows all the way through to the code installed in the image: --build-arg → Dockerfile ARG → sed rewrite of requirements.txt → pip install -e git+…@<ref> → the git ref checked out inside the image.

Built two images locally and inspected the commit pip actually checked out at /task/src/digital-land:

Test 3 — End-to-end Docker build (local)

Proves the digital_land_python_ref build-arg flows all the way through to the code installed in the image: --build-arg → Dockerfile ARG → sed rewrite of requirements.txt → pip install -e git+…@<ref> → the git ref checked out inside the image.

Built two images locally and inspected the commit pip actually checked out at /task/src/digital-land:

docker build --build-arg DIGITAL_LAND_PYTHON_REF=main -t ct:main .
docker build --build-arg DIGITAL_LAND_PYTHON_REF=162-add-data-command-1 -t ct:feat .

docker run --rm ct:main bash -lc 'git -C /task/src/digital-land rev-parse HEAD'
docker run --rm ct:feat bash -lc 'git -C /task/src/digital-land rev-parse HEAD'

image (build-arg ref)	HEAD baked into image	expected (remote tip)	result
main (default/control)	fb9f0013f0621bb643eec1088d3d883d5ee7cb1e	fb9f001 (refs/heads/main)	match ✅
162-add-data-command-1 (feature)	6e904bbd206f0ffa5598e83d7490aeb162feb0f7	6e904bb (refs/heads/162-add-data-command-1)	match ✅

The control build (main) confirms default behaviour is unchanged; the feature build confirms an arbitrary digital-land-python ref is baked into the image as intended.

Test 4

Which I haven't done but will do before merging and the next time its not 3:30pm on a Friday afternoon.

I'm going, run the new workflow from branch and just deploy main of both collection-task and digital-land-python to PROD, and check it all runs fine.

I'm then going to run the new workflow from branch and deploy a digital-land-python feature branch to staging, and check all runs fine.

Added/updated tests?

We encourage you to keep the code coverage percentage at 80% and above. Please refer to the Digital Land Testing Guidance for more information.

• Yes
• No, and this is why: not really sure one does tests on infrastructure like this.
• I need help with writing tests

[optional] Are there any post deployment tasks we need to perform?

[optional] Are there any dependencies on other PRs or Work?