Also should wait until the container is finished creating

Should we restructure using reusable workflows to achieve this, now that we know they work?

Potentially, there is also an argument for restructuring upstream in https://github.com/DiamondLightSource/python3-pip-skeleton and merging to here. @gilesknap any thoughts?

Plans for https://github.com/DiamondLightSource/python-copier-template align with this so should be resolved by #359

@callumforrester the issue description is unclear, I guess this is solved now with #359

@stan-dot this issue is not resolved and I agree it needs more description:

Typically in a Github release pipeline, you want actions to depend on one another so that broken artefacts are not published, for example there is no point in uploading to PyPi or publishing a container image if the tests won't even pass.
Currently we have a Github actions job for publishing the helm chart on a release, and it doesn't seem to have any dependencies because it will try to package and publish a chart even if other jobs fail. It should be one of the last steps in the pipeline and should depend on the container build at the very least.

Acceptance Criteria

• Helm publishing job depends on container successfully building and publishing
• If the container fails, no new helm chart is published

We might still want to create a Helm chart as part of an earlier step in case we make a breaking change to it, but not publish unless everything works.

Agreed, there should be a job to lint the chart and another one to publish it