https://pantsbuild.org/ logo
Join Slack
Powered by
Thinking of making a Packer plugin. Integrating sh...
# development
f
Thinking of making a Packer plugin. Integrating shouldn’t be too hard because Packer is pretty simple. But what existing goal does 
packer build
map to? Package? Publish? Seems like both to me. Anyone familiar with it have any thoughts?
e
It's been a while, but isn't it the case that 
HCP_PACKER_REGISTRY=0
allows 
packer build
to be just package with no publish? If so, that could allow structuring rules to split the steps if that is desirable.
w
Docs for publish...
Publish deliverables (assets, distributions, images, etc).
Hmm... To me, publishing feels like pushing an artifact to a remote location. Would be nice to have some more content in there - especially with 
experimental-deploy
packer build
feels itself more like 
package
(assuming it stays local)... It's been a while since I've used it so I can't recall - does it auto-publish as well?
f
Yeah that’s the thing…. Packer can stay local but it’s usually in the cloud. It really depends on what you’re building. You can build VM images locally but if you build an Amazon AMI it’s all in the cloud. And it registers an image in the cloud on your account
I think 
package
makes sense, even if this "packaging" is happening on a cloud and only can be referenced within the semantics of that cloud. Packer is explicitly not a tool for managing images, just building them. This is complicated by stuff you can do with post-processors, but I'll probably get into that more as I dive into the details
h
Thing is, 
package
today assumes that it has no side-effects (except writing into distdir) so we’d have to be sure that is still true? E.g., that 
./pants package
remains idempotent, and that normal caching/concurrency semantics apply
f
What about Docker packaging? That writes to dockers storage. I was thinking that was a bit more similar
h
True
And that has caused subtle bugs!
But if it’s similar to that then it’s reasonable for 
package
to be the goal for 
packer build
, as long as it’s done carefully
This is the docker package bug I was referring to: https://github.com/pantsbuild/pants/issues/16101
So we can avoid it with packer
f
Hopefully. But I'll keep thinking about this. It's possible there should be a new goal for this.
h
I hope it doesn’t come to that 🙂
w
Yayyy fewer goals!!! Booo more goals... 🙂
f
There's an argument to be made that what packer does is actually a 
deploy
but... only for its cloud backends. It also will build images on a local filesystem that could run in e.g. virtualbox
c
My recollection of Packer was that it would spin up a VM with whatever build backend you had, run your build scripts, prep an image from that, and then move the image to the image gallery. I don't know if it's possible to separate the image build from the image push automatically. Having the image end up in the image gallery seems like it would require the 
publish
goal. To me, the docker 
package
writing to the local image store is definitely different than the image ending up in a repository.
f
That's the thing... in the cloud you don't have access to an image if it isn't in the image gallery. In practice, I've seen teams maintain a separate mini-db of which images are "verified" or "current" to model publishing them in a more conventional sense
Open in Slack
PreviousNext
Powered by