Improve support for monorepo by supporting git options such as depth, and sparse checkout
# Summary There are many situations where having more control over how git operates is very valuable. ### Set checkout directory This would checkout only the subfolder specified. ```yaml apiVersion: argoproj.io/v1alpha1 kind: Application spec: syncPolicy: syncOptions: - git_checkoutdir=yamls/ ``` This could be the equivalent of `git checkout <remote>/<branch> -- relative/path/to/file/or/dir` or a true sparse checkout like `git config core.sparseCheckout true` if doing the latter it would need to be a setting on the repository. ### Set checkout depth Rather than pulling the entire history (default) this would allow specifying the depth to collect. ```yaml apiVersion: argoproj.io/v1alpha1 kind: Application spec: syncPolicy: syncOptions: - git_depth=1 ``` ### Setting git options on repos For something like depth, a `maxdepth` would make more sense to restrict applications using that repository. ```yaml apiVersion: v1 kind: Secret metadata: name: private-repo namespace: argocd labels: argocd.argoproj.io/secret-type: repository stringData: type: git git_maxdepth: 1 ``` # Motivation When using a large monorepo, checking out the entire repo may be slow, or too resource intensive. Some users have reported crashes from repos being too large. Both git depth, and sparse checkout would greatly improve the monorepo support. # Proposal Introducing these fields could be done pretty easily in reposerver, basically we can set a default value that
Posted by todaywasawesome on Nov 4, 2022, 8:20 PM
Tags
Related issues
- The only thing keeping me on VSCode these days is the remote SSH development.
- Something similar was done in a sheep model: "A bioactive supramolecular and covalent polymer scaffold for cartilage repair in a sheep m...
- Proposal for OpenHarmony Adaptation of [ ThreadPool ]
- Proposal for a pipe-like operator to chain constructor/method invocations without nesting
- Implement support for Node Stashing
- RSC and CDN interaction makes next.js inefficient for highload projects
Raise real-world problems, find people facing the same issue, and discuss solutions.2,500 issues0 comments
support (E-commerce)
The only thing keeping me on VSCode these days is the remote SSH development.
Something similar was done in a sheep model: "A bioactive supramolecular and covalent polymer scaffold for cartilage repair in a sheep m...
Proposal for OpenHarmony Adaptation of [ ThreadPool ]
Proposal for a pipe-like operator to chain constructor/method invocations without nesting
Implement support for Node Stashing
RSC and CDN interaction makes next.js inefficient for highload projects
Extract Action Notifier framework for push notifications
Improve support for monorepo by supporting git options such as depth, and sparse checkout
Improve support for monorepo by supporting git options such as depth, and sparse checkout
# Summary There are many situations where having more control over how git operates is very valuable. ### Set checkout directory This would checkout only the subfolder specified. ```yaml apiVersion: argoproj.io/v1alpha1 kind: Application spec: syncPolicy: syncOptions: - git_checkoutdir=yamls/ ``` This could be the equivalent of `git checkout <remote>/<branch> -- relative/path/to/file/or/dir` or a true sparse checkout like `git config core.sparseCheckout true` if doing the latter it would need to be a setting on the repository. ### Set checkout depth Rather than pulling the entire history (default) this would allow specifying the depth to collect. ```yaml apiVersion: argoproj.io/v1alpha1 kind: Application spec: syncPolicy: syncOptions: - git_depth=1 ``` ### Setting git options on repos For something like depth, a `maxdepth` would make more sense to restrict applications using that repository. ```yaml apiVersion: v1 kind: Secret metadata: name: private-repo namespace: argocd labels: argocd.argoproj.io/secret-type: repository stringData: type: git git_maxdepth: 1 ``` # Motivation When using a large monorepo, checking out the entire repo may be slow, or too resource intensive. Some users have reported crashes from repos being too large. Both git depth, and sparse checkout would greatly improve the monorepo support. # Proposal Introducing these fields could be done pretty easily in reposerver, basically we can set a default value that
Comments (0)
No comments yet. Start the discussion.