I like this idea a lot. It gets Lagoon to address the concurrency issue, rather than requiring all codebases do it. Additional thoughts:

• A sha256 looks like e4206b8e5676ba55d13203d06fe9004ff1e2bb848d74d0c7daac1ea0cafdf30b (for example), this is far too long, likely you can just pick the first 8 chars and be happy

$ echo "$command" | sha256sum | awk '{ print $1 }'
e4206b8e5676ba55d13203d06fe9004ff1e2bb848d74d0c7daac1ea0cafdf30b

$ echo "$command" | sha256sum | awk '{ print $1 }' | cut -c 1-8
e4206b8e

• the lock file should end in .lock, so it is more obvious what it is
• run flock with the argument --verbose so lock failures are obvious

So perhaps:

/lagoon/entrypoints.sh flock --verbose -n /tmp/cron-$(echo "$@" | sha256sum | awk '{ print $1 }' | cut -c 1-8).lock sh -c "$@"

thanks for the feedback 😄

A sha256 looks like e4206b8e5676ba55d13203d06fe9004ff1e2bb848d74d0c7daac1ea0cafdf30b (for example), this is far too long, likely you can just pick the first 8 chars and be happy

I'm not sure about this. it's only every meant to be machine readable and there doesn't seem to be much point in adding another command to the pipeline for aesthetics.

the lock file should end in .lock, so it is more obvious what it is

I'm not sure I understand this. The file already is named cron.lock.*?

run flock with the argument --verbose so lock failures are obvious

Unfortunately this is GNU specific. Busybox flock (that alpine uses) doesn't have this flag.