When using tag_filter, the version reported by 'in' should be the tag name #45
Comments
|
Hi there! We use Pivotal Tracker to provide visibility into what our team is working on. A story for this issue has been automatically created. The current status is as follows:
This comment, as well as the labels on the issue, will be automatically updated as the status in Tracker changes. |
|
Without this patch, a pipeline like this:
which is triggered by tags, will use the tag as input of the first job and then the hash. The git resource will report these versions:
Where first is a tag, that is input of the first job, and then a hash that is the input of the next jobs. |
|
I've also seen this, but only intermittently:
The configuration for this resource is: - name: broker-release-final
type: git
source:
uri: git@github.com:CLASSIFIED/TOP-SECRET.git
branch: master
private_key: {{private_key}}
tag_filter: "v*" |
|
@tomwhoiscontrary Yeah, it matches with my issue description. That is because the hash is generated when the resource is consumed by a task by using the In our case we trigger the pipeline with that git resource, so every commit triggers a job which calls You can see which job generated the "hash" version by using it as input by clicking in the version:
You can see that in our case, that version "inputs to"... |
When using tag_filter, the check step will return a list of valid tags as versions. In order to keep consistency, the get command should also return the tag if the tag_filter is defined. This implementation will try to check if $ref is a tag, if not use the latest tag, if not use the hash reference. Fixes concourse#45
When using tag_filter, the check step will return a list of valid tags as versions. In order to keep consistency, the get command should also return the tag if the tag_filter is defined. In this test we verify that we return the latest tag matching tag_filter that points to $ref, regardless $ref is a tag, a hash or if it matches or not tag_filter. If no tags match it, we will return the hash pointer to $ref. Tests concourse#45
The in command will check if tag_filter is defined in the source configuration, and if so, will return the matching tag as a version or the hash if none match. In this implementation if several tags match, we order the tags by version number and return the latest one. Fixes concourse#45
The in command does checkout the code at a given ref, but it does not change it. In consequence it should report the same ref as passed from concourse as version to checkout. We only return a different version in the case no version is specified by concourse (first get). For instance when using tag_filter, the check step will return a list of valid tags as versions. In order to keep consistency, the get command should also return the tag if the tag_filter is defined. We include a test to verify that get reports the same version for different ref (hash or tag) pointing to the same commit. Fixes concourse#45
When using
tag_filter, thecheckcommand reports the tag name instead of the hash in the version listBut then the
incommand returns the hash not the tagI think it should report the tag if available.
The text was updated successfully, but these errors were encountered: