resource interface for embedded/integrated resources

[jtarchie]

👋

tl;dr: What do you think of native resources? Having git-resource actually being build into bass using go-git, rather than an external container image.

Having used the previous Concourse, the extension for resources for always the most powerful feature.
The interface has been extended with bass, where it supports native resources calling out to their concourse/*-resource container image.
An itch I've always had, could the concourse worker have had the resource native to the binary? This means it would've been executed code in the concourse worker, rather than delegating to a container image.
For example, the git-resource uses linux, git cli, etc. Could the go-git library be used to support some most all of the features of the git-resource

[vito]

yo!

Are you just curious? Happy to chat trade-offs and I'm curious what kinds of things it'd enable, but right now I mainly see downsides and don't have a technical motivation for this yet.

I'm not keen on straying from git. IMO CLIs rule the world; they set the standard for UX and backwards compatibility. The user will probably know the flags, and they'll probably have an easier time troubleshooting error messages. I'd guess the git CLI is also the main focus for performance optimizations.

I think a native Git implementation in Bass would have a similar maintenance burden to the Git resource itself. It started simple and pure, but it grew really complicated as everyone's requirements were centralized. For the user, it introduced a dependency on a third party for receiving git updates. I think this overhead would distract from the fun parts of Bass.

I'd like to try to avoid all that by making CLIs the most obvious thing to use, and make them easy to abstract if needed. The recent changes (9b78421 + #6 (comment)) feel like a pretty good direction, and in as far as I've dogfooded it¹ I haven't felt the need for anything more than just installing and using CLIs.

So yeah, not really motivated to go down this path myself at the moment, but this whole project is for fun so if there are interesting outcomes to weigh I'm still curious.

Footnotes

1. which is to say not very much, but see ci/, ci/test, and ci/git.bass ↩