Terragrunt project failing to apply due to locks acquired when planning PR

[carcunha]

I had this project that is failing to apply, seems to be around the locks due to the messages posted on the logs. I checked the code, and it gets past line https://github.com/diggerhq/digger/blob/77ee0b1a082838696cb46dad872016790643f9ab/cli/pkg/digger/digger.go#L392 because of the message, then somehow it doesn't apply:

Following commands are going to be executed:
project: organizations_fastnorth_repositories_github-actions: commands: "digger apply", 
project: organizations_fastnorth_repositories_github-docker-build: commands: "digger apply", 
project: organizations_fastnorth_repositories_github-ecs-deploy: commands: "digger apply", 
project: organizations_fastnorth_repositories_github-ecs-job-controller: commands: "digger apply", 
project: organizations_fastnorth_repositories_github-stats: commands: "digger apply", 
project: organizations_fastnorth_repositories_github-tf-static-analysis: commands: "digger apply", 
project: organizations_fastnorth_repositories_github-utils: commands: "digger apply", 
Running 'digger apply' for project 'organizations_fastnorth_repositories_github-actions' (workflow: default)
PR status, mergeable: true, merged: false
Skipping plan policy checks because plan storage is not configured.
Lock fastnorth/terraform-github#organizations_fastnorth_repositories_github-actions
Lock result: false
Running 'digger apply' for project 'organizations_fastnorth_repositories_github-docker-build' (workflow: default)
PR status, mergeable: true, merged: false
Skipping plan policy checks because plan storage is not configured.
Lock fastnorth/terraform-github#organizations_fastnorth_repositories_github-docker-build
Lock result: false
Running 'digger apply' for project 'organizations_fastnorth_repositories_github-ecs-deploy' (workflow: default)
PR status, mergeable: true, merged: false
Skipping plan policy checks because plan storage is not configured.
Lock fastnorth/terraform-github#organizations_fastnorth_repositories_github-ecs-deploy
Lock result: false
Running 'digger apply' for project 'organizations_fastnorth_repositories_github-ecs-job-controller' (workflow: default)
PR status, mergeable: true, merged: false
Skipping plan policy checks because plan storage is not configured.
Lock fastnorth/terraform-github#organizations_fastnorth_repositories_github-ecs-job-controller
Lock result: false
Running 'digger apply' for project 'organizations_fastnorth_repositories_github-stats' (workflow: default)
PR status, mergeable: true, merged: false
Skipping plan policy checks because plan storage is not configured.
Lock fastnorth/terraform-github#organizations_fastnorth_repositories_github-stats
Lock result: false
Running 'digger apply' for project 'organizations_fastnorth_repositories_github-tf-static-analysis' (workflow: default)
PR status, mergeable: true, merged: false
Skipping plan policy checks because plan storage is not configured.
Lock fastnorth/terraform-github#organizations_fastnorth_repositories_github-tf-static-analysis
Lock result: false
Running 'digger apply' for project 'organizations_fastnorth_repositories_github-utils' (workflow: default)
PR status, mergeable: true, merged: false
Skipping plan policy checks because plan storage is not configured.
Lock fastnorth/terraform-github#organizations_fastnorth_repositories_github-utils
Lock result: false
Commands executed successfully
Digger finished successfully

[motatoes]

Hi there, thanks for reporting! Seems you are using digger in backendless mode. Any more context around your workflow file and digger.yml would help debug firthwr the issue

[carcunha]

This is my digger.yml:

---
allow_draft_prs: true
generate_projects:
  blocks:
    - block_name: fastnorth
      root_dir: organizations/fastnorth/
      terragrunt: true
      terragrunt_parsing:
        parallel: true
        createProjectName: true
  auto_merge: true

And this is my workflow file:

---
name: Digger terraform CI

on:
  pull_request:
    branches: ["main"]
    types: [closed, opened, synchronize, reopened]
  issue_comment:
    types: [created]
    if: contains(github.event.comment.body, 'digger')
  workflow_dispatch:

jobs:
  digger:
    permissions:
      actions: write        # required for plan persistence
      contents: write       # required to merge PRs
      id-token: write       # required for workload-identity-federation
      pull-requests: write  # required to post PR comments
      statuses: write       # required to validate combined PR status

    runs-on: ubuntu-latest
    timeout-minutes: 60  # Same as the OIDC validtity time for now

    steps:
      - name: digger run
        uses: diggerhq/digger@v0.5.11
        with:
          setup-aws: true
          aws-role-to-assume: "arn:aws:iam::************:role/tf/github-terraform-digger"
          setup-terraform: false
          setup-tfenv: true
          setup-terragrunt: true
          terragrunt-version: 0.58.14
          configure-checkout: true
          no-backend: true
          cache-dependencies: true
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          GITHUB_CONTEXT: ${{ toJson(github) }}
          TF_VAR_github_token: ${{ secrets.ADMIN_TOKEN }}

[carcunha]

One more piece of information. I just tried issueing a digger unlock first. And then another digger apply. Then it works. But the lock was acquired when the PR was opened, and I believe that a digger apply for that same PR should re-use that same lock, and unlock when it's finished applying, and then merge.

[opp-svega]

I am having a similar issue, when I create a pull request my plan runs. But if i were to commit again to the same pull request, i have to unlock manually and then manually run digger plan before a plan run agains. Once i have a successful plan, i have to run digger unlock and then digger apply to apply my terraform.

[carcunha]

I rolled back to v0.5.10 and it's working as expected now. So the issue seens to have been introduced on 0.5.11

[motatoes]

Thanks folks for chiming in with these details to repro. Thanks @carcunha for helping pinpoint the version of the error. I'm suspecting its related to our recently introduced flag in digger.yml to disable locking from there #1586 #1578 so will start to look from there for something that could have caused it.