Feature idea: send repository_dispatch to many repositories

[efasel]

https://ee.public.springernature.app/rel-eng/github-actions/overview/#self-hosted_runners says:

Unlike Concourse, GitHub Actions does not support watching for events external to the repository. e.g. an updated docker image or a workflow completing.

Idea: send repository-dispatch event for docker-push to a list of optional repositories

Example halfpipe file before:

tasks:
  - name: push image
    type: docker-push
    image: {image-name}

Example halfpipe file after:

tasks:
  - name: push image
    type: docker-push
    image: {image-name}
    dispatch-repositories:
      - springernature/{some-repository}
      - springernature/{another-repository}

We would only need to add additional repositoryDispatch steps for each repository in the dispatch-repositorieslist here and add the repository here as repository attribute.

Example repositories:

• repo with trigger: https://github.com/springernature/test-repo-dispatch-trigger/actions/workflows/repo-dispatch-trigger-halfpipe.yml
• repo with receiver: https://github.com/springernature/test-repo-dispatch-receiver/actions/workflows/repo-dispatch-receiver-halfpipe.yml

Maybe one of @springernature/ee-release-engineering would like to do a small 10% time project with me on that? 😃

[simonjohansson]

The tasks are meant to be generic across CI systems. This would introduce a lot of Actions specific code across the code base which I don't think would outweigh the utility if Im honest.

You can already simulate this(although, a bit cumbersome) by just issue dispatch events yourself in a task.

Not sure what @robwhitby or @stigtermichiel thinks.

[efasel]

The tasks are meant to be generic across CI systems.

Good point, I didn’t think of that.

On the other hand it would bring the behaviour of "trigger on an image has been pushed event" on Concourse and GitHub action closer together by allowing this as well on GitHub Actions. 😃

This would introduce a lot of Actions specific code across the code base which I don't think would outweigh the utility if Im honest.

Would it? I would have hoped by what I saw that it would be a rather small change. 🤞

And for Concourse pipelines this could simply be ignored as the event works already across different repositories.

[efasel]

You can already simulate this(although, a bit cumbersome) by just issue dispatch events yourself in a task.

But then I need to manually modify the action generated by halfpipe, right? And I really think that it is very beneficial for most users to keep using halfpipe as long as possible.

[efasel]

But this idea is definitely neither urgent nor important.

[simonjohansson]

Would it? I would have hoped by what I saw that it would be a rather small change. 🤞

Well, we would have to add listing rules, e2e tests, actual integration tests, make sure our dispatch token is working correctly everywhere etc etc.

| But then I need to manually modify the action generated by halfpipe, right?

I mean something like

tasks:
- type: docker-push
  name: build image
   ....
- type: run
   script: notify-with-dispatch-events
   vars:
     repos: springernature/repo1,springernature/repo2

[robwhitby]

yeah I think start with a run task and then maybe we could make it a proper halfpipe task type in the future

[efasel]

Works, but doesn’t look really nice, at least this initial attempt hack:

• https://github.com/springernature/test-repo-dispatch-trigger/blob/main/.halfpipe.io.yml
• https://github.com/springernature/test-repo-dispatch-trigger/blob/main/repository-dispatch.sh

But, as I said: this is neither urgent nor important. 😄

[efasel]

Feel free to close this issue if you want.

[robwhitby]

nice one, good to have a working example

small thing - the first 2 variables are also env vars - GITHUB_REPOSITORY and GITHUB_WORKFLOW - so you could read them directly in the script

[efasel]

small thing - the first 2 variables are also env vars - GITHUB_REPOSITORY and GITHUB_WORKFLOW - so you could read them directly in the script

Nice!

-> Default environment variables

[efasel]

Finished, and a little polished.