concourse / concourse/pool-resource

empty metadata updates result in a vague error and update infinite loop

Open
#69 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
Go
Stars
59
Forks
39
PR merge metrics
No merged PRs in 30d

Description

Describe the bug

For the update action if the metadata file is not changed we get a vague error:
failed to update the lock: bootstrap-terragrunt-builds-lock! (err: exit status 1) retrying...
and the task is stuck in an infinite update loop, can't even abort the pipeline.

I found that if I do change the content of the file every time it will not error out.
So I can only assume that exit status 1 is probably git erroring out during one of the git commands, likely git commit

I suggest that the code is changed to cater for that scenario.

// Check if there are any changes
status, err := glh.git("status", "--porcelain")
if err != nil {
    return "", err
}

// If there are changes, commit them
if status != "" {
    commitMessage := glh.messagePrefix() + fmt.Sprintf("%s: %s", operation, lockName)
    _, err = glh.git("commit", lockPath, "-m", commitMessage)
    if err != nil {
        return "", err
    }
}

as above, I would very naively just run commit if there are changes but there might be other parts involved that I am not aware of.

Reproduction steps

Run the following pipeline (change the lock repo accordingly), twice, to test:

meta:
  # Secrets that are populated by the global credentials manager or var_sources
  secrets:
    github_private_key: &github_private_key ((github-private-key))

resources:
  - name: terragrunt-builds-locks
    type: pool
    source:
      uri: git@github.com:<<your-repo-here>>.git
      branch: main
      pool: bootstrap-terragrunt-builds
      private_key: *github_private_key

jobs:
  - name: claim-lock
    plan:
      - in_parallel:
          fail_fast: true
          steps:
            - get: terragrunt-builds-locks
              trigger: false
              params:
                depth: 10

      - task: create-lock-info
        output_mapping:
          output: bootstrap-terragrunt-builds-lock-info
        config:
          image_resource:
            type: docker-image
            source: {repository: busybox}
          platform: linux
          outputs:
            - name: output
          run:
            path: sh
            args:
            - -cex
            - |
              WORKDIR="${PWD}"
              # create a lock-info file that contains the lock name and
              # the lock metadata for the pool resource to consume
              echo "bootstrap-terragrunt-builds-lock" > ${WORKDIR}/output/name
              echo "TEST" > ${WORKDIR}/output/metadata

      - put: terragrunt-builds-locks-update
        resource: terragrunt-builds-locks
        params:
          update: bootstrap-terragrunt-builds-lock-info

      - put: terragrunt-builds-locks-claim
        resource: terragrunt-builds-locks
        params:
          claim: bootstrap-terragrunt-builds-lock

      - put: terragrunt-builds-locks-release
        resource: terragrunt-builds-locks
        params:
          release: terragrunt-builds-locks-claim

it will succeed the first time and fail the second time.

Expected behavior

to not fail if the metadata file content is not changing

Additional context

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the update action and its git status/commit handling, then reproduce the provided pipeline twice with unchanged metadata. Done means the second update does not fail or enter an infinite retry loop, while the existing lock behavior remains intact.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
devops
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.