https://pantsbuild.org/ logo
f

flat-zoo-31952

11/26/2022, 3:23 PM
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

enough-analyst-54434

11/26/2022, 3:45 PM
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

wide-midnight-78598

11/26/2022, 4:01 PM
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

flat-zoo-31952

11/26/2022, 7:43 PM
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

happy-kitchen-89482

11/27/2022, 2:25 PM
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

flat-zoo-31952

11/28/2022, 1:35 AM
What about Docker packaging? That writes to dockers storage. I was thinking that was a bit more similar
h

happy-kitchen-89482

11/28/2022, 1:30 PM
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

flat-zoo-31952

11/28/2022, 1:48 PM
Hopefully. But I'll keep thinking about this. It's possible there should be a new goal for this.
h

happy-kitchen-89482

11/28/2022, 4:33 PM
I hope it doesn’t come to that 🙂
w

wide-midnight-78598

11/28/2022, 6:03 PM
Yayyy fewer goals!!! Booo more goals... 🙂
f

flat-zoo-31952

11/28/2022, 6:03 PM
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

careful-address-89803

12/04/2022, 1:46 AM
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

flat-zoo-31952

12/05/2022, 2:51 PM
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