Emit a repository_dispatch event of type "docker-push:$image"

[efasel]

It would be awesome if ee-action-buildpack the halfpipe task buildpack would emit a repository_dispatch event of type "docker-push:$image" so that docker trigger also works with CNB.

I think this would be the minimal fix:

diff --git a/renderers/actions/buildpack.go b/renderers/actions/buildpack.go
index 3a3e71be..ae2a4502 100644
--- a/renderers/actions/buildpack.go
+++ b/renderers/actions/buildpack.go
@@ -34,5 +34,5 @@ func (a *Actions) buildpackSteps(task manifest.Buildpack) (steps Steps) {
 		},
 	}
 
-	return Steps{step}
+	return Steps{step, repositoryDispatch(task.Image)}
 }

Use case: two pipelines, one which builds an application image, a second one which deploys the Katee application if the image has changed.

Example:

• statuspage-to-teams-image
• statuspage-to-teams

[efasel]

The "fix" above would simply align the behaviour of docker-push with buildpack in regard to the repository dispatch, not more and not less, I think.

See

halfpipe/renderers/actions/docker_push.go

Line 50 in 45f0cfe

return Steps{push, repositoryDispatch(task.Image)}

[simonjohansson]

So how would we communicate the version of the build docker image across the repos boundaries?

[efasel]

Well, we don’t do this at the moment in Concourse. The trigger type: docker would then only work an Concourse and on GitHub Actions. Not more, not less.

https://ee.public.springernature.app/rel-eng/halfpipe/manifest/#docker

# Trigger when a docker image is updated
- type: docker
  image: "eu.gcr.io/halfpipe-io/halfpipe-example-docker"

[simonjohansson]

Yes, but what you are proposing is more akin to git ops with deployment, not generic trigger when a docker image has updated?

[efasel]

Maybe there is a misunderstanding. Maybe it’s just me not getting it. :-\

The mechanism being proposed is just event plumbing — it doesn't impose a GitOps model, it just makes the existing docker trigger work consistently regardless of whether the image was built with docker-push or buildpack. The semantics of what the downstream pipeline does (deploy, scan, notify) is left entirely to the consumer. Today, if you switch from docker-push to buildpack, downstream pipelines silently stop triggering. It’s more or less just a parity gap.

Is there any downside to close this gap?

[efasel]

It would be awesome if ee-action-buildpack

Typo in the original description. This is not about ee-action-buildpack but about halfpipe.

[simonjohansson]

@efasel perhaps best to have a call and clarify our misunderstandings :)

[efasel]

Let’s do this! After my holiday. See you in three weeks. 🌞