Resource git check only returns 'x' commits

[AClarkie]

I'm trying to understand why in concourse if I click the check endpoint I only get a limited number of refs listed. Can someone explain how this works?

api/v1/teams/<team>/pipelines/<pipelinename>/resources/git_repo_master/check

[jamieklassen]

https://github.com/concourse/git-resource/blob/master/assets/check is the code that runs checks for the git resource -- it's a bit convoluted but you might get some insights if you analyze it carefully. Reading between the lines, it strongly seems like you're saying "I need 'y' commits, 'x' is too few" or perhaps "where is commit abc? it's older than the 'x' i can see but it's really important". What are you trying to achieve?

EDIT: here is a bit more general context on what resource checking is and how it works: https://concourse-ci.org/implementing-resource-types.html#resource-check

[AClarkie]

I'd like to set the number of commits that is returned say 30? Is there an easy way to configure that?

[jamieklassen]

When you say

I'd like to set the number of commits that is returned

We'd need to chat a little bit more about exactly what that means, because there are plenty of cases where the resource page will show more commits over time, see https://ci.concourse-ci.org/teams/main/pipelines/concourse/resources/concourse which has 100s, for example. Do you mean that you want a "fresh" pipeline to show 30 commits on the resource page? like on the first check? do you want there to always be a fixed 30 commits visible, like as new ones are discovered, old ones get cleaned up?

Setting that aside for a minute I'm wondering if you want this "show 30 commits" idea to hold for a single resource, or for all resources in a pipeline, or perhaps for all resources across an entire cluster (like if you're operating a cluster on behalf of multiple tenants). It's not configuration that's exposed on the git resource because we've never imagined a use case for it.

I'll try to reframe my initial question a bit more carefully as well -- what is the outcome you want? what is it that having 30 commits appear will do for you that you are currently prevented from doing? is it a one-off problem or something more generic? In the majority of cases people who are asking questions like this really want a particular version to appear to get themselves unstuck, so normally I mention the --from flag on fly check-resource: https://concourse-ci.org/managing-resources.html#fly-check-resource.

[AClarkie]

To provide a bit of background we have a pipeline with a number of tasks, see this image:
https://imgur.com/a/UMI06Xt

git_repo_master is a resource of type git.

We had a requirement to roll back to an earlier commit following a bad deploy but the list of commits in git_repo_master did not go back far enough. Hence the requirement to list up to say 30 commits to ensure we can select and rollback. I hope that makes sense

[jamieklassen]

sounds like fly check-resource --from ref:<the commit you want to roll back to> would do the trick to get the version to appear, and then you could pin to it and trigger whatever jobs you need to. it's an extra step/workaround, but the requirement that 30 commits exist in the version history at any given time is a delicate one that would probably require changes to the git resource itself. If you really need it, I'd encourage you to try forking https://github.com/concourse/git-resource.

[AClarkie]

Excellent, thanks for your help with this.