concourse / concourse/git-resource
After pushing a tag, the tag disappears on rebuilds
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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