introduce workflow_file argument in digger.yml

[motatoes]

currently in digger orchestrator always triggers digger_workflow.yml job

for multi-account setups we have OIDC project-specified role (aws only) and we have environment variable mapping. The drawback for specifying OIDC role in digger.yml is that we need to support it for every different provider. The drawback of environment mapping is that all environments exist in a single workflow.

I propose to introduce workflow_file as an argument to projects in order to allow users to specify target provider (aws account, gcp account, azure subscription etc) within different workflow files and alllow the orchestrator to trigger the right file without knowledge about it

# digger.yml
projects:
     name: dev
     dir: dev
      workflow_file: digger_dev.yml
     name: prod
     dir: dev
     workflow_file: digger_prod.yml

#.github/workflows/digger_dev.yml
name: Digger Workflow
..........
..........
    steps:
      - uses: actions/checkout@v4
      - uses: diggerhq/digger@latest
        with:
          setup-aws: true
          aws-access-key-id: ${{ secrets.DEV_AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.DEV_AWS_SECRET_ACCESS_KEY }}
........
.........

#.github/workflows/digger_prod.yml
name: Digger Workflow
..........
..........
    steps:
      - uses: actions/checkout@v4
      - uses: diggerhq/digger@latest
        with:
          setup-aws: true
          aws-access-key-id: ${{ secrets.PROD_AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.PROD_AWS_SECRET_ACCESS_KEY }}
........
.........

This offers much more flexibility when using digger with an orchestrator

[chvima]

Great, I wanted to suggest the same. My use case is to use different github workflow files per environment (DEV/PROD), to setup different github runners config and different roles.

What do you think about instead of suggested argument per project, to implement it per (digger) workflow?
https://docs.digger.dev/reference/digger.yml#workflows

[motatoes]

oops @chvima just seeing your comment now 😂

I've implemented a WIP at the project level in #1232 the reason I initially had thought about it at project level is because you would always have a project but not necessarily have a workflow defined so it covers about everyone. It can also be passed on from the projects generation feature.

However I don't see why in the future we should not support it to be at the workflow level too, but overridable at the project level :) what do you think ?

[chvima]

Yes that would be great!
It's only a cosmetic to have more less lines in the digger.yaml for me though, I am happy also with the current implementation, that enables this feature, thank you.

[aaron-jones-provi]

+1 on this, when trying to work through the "generate_projects" portion of the documentation to enable more dynamic workflows, I kept getting a 404 from the Digger GHA app