digger icon indicating copy to clipboard operation
digger copied to clipboard

Allow using workflow from branch

Open ZIJ opened this issue 1 year ago • 5 comments

Reported by @fleroux514:

When posting a digger command, the workflow (digger) in the master branch is used vs the PR change

  • eg Renovate PR that updates Terraform from 136 --> 1.5.1.
  • I added a commit in that PR to tell digger to install TF 1.5.1.
  • but when I run digger plan it uses digger from the master branch wjth TF 1.3.6 so it fails
  • Need to force a synchronize to the branch in order to plan correctly
  • But digger apply fails for the same reason

as a workaround, I decided to use the option to install and use tfenv instead of specifying a specific terraform version in digger. But the same problem manifested itself when I tried git apply on that PR, since it uses digger from the master branch which does not install tfenv so my tfenv cmd would fail during apply.

@Spartakovic:

  • it’s because github actions uses default branch when running action triggered by pull request comments.
  • you will have to update action on the main branch for it to work unfortunately.
  • it’s very inconvenient, but apart from eventual move to webhooks not sure if there is much we can do right now
  • I will think about it more

ZIJ avatar Jun 22 '23 09:06 ZIJ

Discussed offline with @Spartakovic @veziak There is potentially another option - to move TF version into digger.yml and handle terraform version within Digger. This however has a major drawback: dealing with the binary from within digger CLI. That's best avoided, especially given that Actions provide a clean way to handle installations of binaries.

Decision: go with the webhooks. That's inevitable anyway. This will likely be part of the same orchestrator backend piece that currently handles RBAC via OPA.

Next step: POC for the webhooks (likely as Github App) to verify that it'd actually work the way it is intended to.

ZIJ avatar Jun 22 '23 13:06 ZIJ

This will likely be part of the same orchestrator backend piece that currently handles RBAC via OPA.

I think the RBAC will remain handled within the cli and not the backend since the cli remains the gatekeeper to decide whether or not a job should run (digger runs all jobs within ci after all)

motatoes avatar Jul 05 '23 10:07 motatoes

This feature requires github app and will be supported with the upcoming dashboard only (cannot be supported in the action-only flow due to a limitation

motatoes avatar Aug 31 '23 16:08 motatoes

has there been any development on this? there still seems to be no way to run digger on say main branch?

this is a major flaw for me which means I have to implement a separate workflow to apply the state since only workflows running on main have sufficient permissions to modify resources, whereas any other branch can only run plans

noxjonas avatar Mar 12 '24 14:03 noxjonas

Hi @noxjonas thanks for following up on this! I am just realising that this issue as per original description has actually already been resolved for a while since the introduction of the orchestrator; it always starts jobs using the workflow file from the PR branch

BUT your issue appears to be different; if I'm understanding you correctly (could well be missing something), the challenge is kind of the opposite: only workflow from main can be used because for any other branch the permissions are insufficient. Is my understanding correct?

ZIJ avatar Mar 12 '24 15:03 ZIJ