carvel-dev / carvel-dev/vendir
`githubRelease` errors on releases without explicit assets
- Dominant language
- Go
- Stars
- 399
- Forks
- 73
- Avg merge
- 2h 53m
- Merged PRs (30d)
- 2
Description
**What steps did you take:**
I attempted to run `vendir sync` with a `githubRelease` for `open-policy-agent/gatekeeper`. The entry under `contents:` looks like:
```yaml
- path: gatekeeper
githubRelease:
slug: open-policy-agent/gatekeeper
latest: true
disableAutoChecksumValidation: true
```
**What happened:**
I get an error that reads `Error: Syncing directory 'config/upstream': Filtering paths in directory 'gatekeeper': Expected to find at least one file within directory.` This error is very cryptic. I spent a few troubleshooting cycles creating empty files in `config/upstream/gatekeeper` or deleting the directory, thinking that the error message was complaining about the local filesystem.
Reading the `vendir` code, the problem seems to be that there’s no particular asset tied to the release - this project doesn’t provide binaries with their releases. You can download the source code, but that’s not listed in the github API json response as part of the assets array.
the release in question: https://api.github.com/repos/open-policy-agent/gatekeeper/releases/37006810
```json
...
"assets": [
],
"tarball_url": "https://api.github.com/repos/open-policy-agent/gatekeeper/tarball/v3.3.0",
"zipball_url": "https://api.github.com/repos/open-policy-agent/gatekeeper/zipball/v3.3.0",
...
```
https://github.com/vmware-tanzu/carvel-vendir/blob/1da965479755f7b3583e275d337e66f6d7a25950/pkg/vendir/fetch/githubrelease/sync.go#L76 refers specifically to the `assets` array, and loops over that array, looking for assets to copy. Finding none, it errors out, apparently at https://github.com/vmware-tanzu/carvel-vendir/blob/bf0685a51eae291131fe5d1475ac0a6eceeb3c1e/pkg/vendir/directory/directory.go#L160
**What did you expect:**
I expected to be able to download the source code, since the Github UI shows it as an available download, and only after looking at the implementation did I understand why the `vendir` `githubResource` was not able to download it. If my project chooses to use `vendir` to track upstream OSS dependencies via `githubResources`, we probably want to track them uniformly, even if they don't ship any specific assets.
I would expect to be able to choose the `tarball_url` or `zipball_url` as options to download, possibly by specifying their paths as they appear when you download them via the github UI: `https://github.com/open-policy-agent/gatekeeper/archive/v3.3.0.zip` and `https://github.com/open-policy-agent/gatekeeper/archive/v3.3.0.tar.gz`
Paths within the sourcecode for the release would also be nice, since in that case we'd probably only need metadata from a small number of files within the release.
**Environment:**
- vendir version (execute `vendir --version`): 0.16.0
- OS (e.g. from `/etc/os-release`): MacOS
Contributor guide
Research direction
Start with pkg/vendir/fetch/githubrelease/sync.go, especially the code that iterates over the GitHub API assets array, and trace the resulting empty directory into pkg/vendir/directory/directory.go. Reproduce the vendir sync failure using a release with no explicit assets, then define and verify support for downloading the release tarball or zipball, including the expected behavior for selecting paths within the source archive.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github, go
- Domain
- cli, release
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100