concourse / concourse/git-resource

After pushing a tag, the tag disappears on rebuilds

Open
#299 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Shell
Stars
203
Forks
305
Avg merge
11d 14h
Merged PRs (30d)
2

Description

Example pipeline:

resources:
- name: repository
  type: git
  source:
    uri: git@github.com:foo/bar.git
    private_key: ((ssh-private-key))
  check_every: 24h
  webhook_token: ((webhook-token))
jobs:
- name: idempotent
  plan:
  - get: repository
    trigger: true
  - task: show-tags
    config:
      platform: linux
      image_resource:
        type: registry-image
        source: { repository: alpine }
      inputs:
      - name: repository
      run:
        path: /bin/sh
        args:
        - -c
        - ls repository/.git/refs/tags
  - put: repository
    inputs: [ repository ]
    params:
      repository: repository
      tag: repository/version
      only_tag: true

for a repository foo/bar containing a file version that may be updated, say, from 1.0.0 to 1.1.0.

The first time this job is built, no tags exist yet, so show-tags shows nothing.
At the end of the first build, the tag in the version file is pushed to the repository.
When the build is re-run, the commit ref hash of HEAD has not changed, so Concourse uses the cached version of the resource instead of fetching / pulling the list of tags from remote.
As a result, on a second build, ls repository/.git/refs/tags shows nothing - even though it should show a file whose name is the contents of the version file, corresponding with the put step in the first build. The tag has, in effect, disappeared from the CI environment.

I'm not sure what the solution is (a separate resource for a repository's tags? the git resource having a more nuanced notion of version than just the commit ref hash?) but this behavior surprised me and I consider it to be a bug.

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 by reproducing the pipeline in the issue, including the show-tags task and the git resource put step. Inspect how the git resource caches a commit ref and obtains remote tags. Done means a rebuild with an unchanged HEAD exposes the tag pushed by the earlier build, or the behavior and intended resource-version semantics are clearly documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
git, shell
Domain
ci-cd
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.