argoproj / argoproj/argo-workflows

Ability to do sparse checkout for git artifact

Open
#10,375 1 comment 9 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
17k
Forks
3.7k
Avg merge
1d 20h
Merged PRs (30d)
138

Description

# Summary

I would like an option for git artifacts to do sparse checkouts so only certain files can be pulled down. This would allow the creation of a step that looks at a certain file in the repo and then launches another step based on the result of that without having to clone the entire repo.

A sparse checkout can be done like this:
```
git clone -b $branch_name -n $git_url /tmp/repo
cd /tmp/repo
git sparse-checkout set $file # example: 'build.yml'
git checkout
```

This can be accomplished using an init container that performs the above steps into an emptyDir, but it would be nice to have a built-in option.

# Use Cases

I am creating a build pipeline triggered by Gitea and would like to configure a generic webhook at the owner level instead of each individual repo. The workflow would contain a step to look at the file build.yml at the root of the repo and then have a step to launch a specific workflow based on the type of build it should run (Maven, NPM, Docker, etc). This would allow a decision to be made without fully cloning the repo twice. This in turn would make it easier to make a single webhook instead of one per build type.

---

**Message from the maintainers**:

Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.

Contributor guide

Open the contributing guide

Research direction

Start by tracing how git artifacts are configured and fetched, then compare that flow with the issue's init-container and emptyDir workaround. Define how a built-in sparse-checkout option should accept a path such as build.yml and verify that only the requested files are fetched while existing artifact behavior remains unchanged.

Written by the indexing model from the issue text.

Assessment

Tech stack
git, kubernetes
Domain
devops, infrastructure
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.