concourse / concourse/docker-image-resource
Laundry list of smells from this resource
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 162
- Forks
- 250
- PR merge metrics
- No merged PRs in 30d
Description
This resource hasn't aged well. We've long suspected a new approach may be necessary, potentially including a complete rewrite and/or breaking it up into separate resource types, each focused on a specific workflow.
I'm going to use this issue as a dumping ground of sorts for now, in hopes that it eventually leads to a more focused direction that can skewer a few of these piranhas at once.
- There are too many knobs, and way too many ways to
put. - The testing situation is improving, but pretty bad.
- Important parts are written in
bashand are subject to thedockerCLI output format changing. Some things are already broken because of this. - There are too many ways to configure credentials.
- There's no caching by default, and it's unclear if everyone would want that.
cache: trueeven pulls down the image willy-nilly, preventing Concourse caching of the image (ironically). (see https://github.com/concourse/docker-image-resource/issues/121, https://github.com/concourse/docker-image-resource/issues/148, https://github.com/concourse/docker-image-resource/pull/188)- Caching all the time is great and all until it's not. Lines like
apt-get update && apt-get -y install foowill need the cache busted in order to get a newfoo.
- Caching all the time is great and all until it's not. Lines like
- There isn't a great way to integrate
Dockerfiles with Concourse-fetched dependencies while also having the image easy to build locally during development (you'd be missing all the dependencies). - There's no way to build without pushing to a registry. To be honest, as a resource that makes sense (there must be an external source of truth), but a reusable task would be great for this.
- It embeds a Docker daemon. Would it be easier to point at an external one? What impact might this have on caching? Would this be an acceptable assumption for most people? How would the resource be pointed at the daemon?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no files or tests; start by reviewing the docker-image-resource implementation and the linked issues #121, #148, and pull request #188. Separate the listed concerns into a focused scope, with an agreed direction and a separately actionable issue as the definition of done.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- bash, docker
- Domain
- devops, infrastructure
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 15/100