https://pantsbuild.org/ logo
w

witty-family-13337

06/21/2022, 8:29 AM
Hello, I put together a document describing the proposal for an
experimental-deploy
goal and a PoC implementation for the Helm backend: https://docs.google.com/document/d/17wZRjiIxM5918ybC_0EnKY42qwd47-1ZporBdua8vRQ/edit?usp=sharing My apologies for how drafty the document feels, having a mix of plenty at my plate and family issues at the moment so I couldn’t dedicate much time to it. Hope that the document plus the PoC Pull Request are useful to trigger a conversation.
🔥 1
👍 4
h

happy-kitchen-89482

06/21/2022, 9:21 AM
Looks like it requires individual access permissions?
w

witty-family-13337

06/21/2022, 9:22 AM
sorry, didn’t notice it, will open the access to it
anyone with the link should have access now
w

wide-midnight-78598

06/21/2022, 12:05 PM
+1 for this. But, I'd be remiss if I didn't mention a conversation @careful-address-89803 and I had briefly re: the deploy goal for the Ansible plugin we're building. In short, I think it comes down to semantically describing and defining what a
deploy
goal means in the Pants world, and if something else would work well enough. A while back, I created this
deploy
goal: https://github.com/sureshjoshi/pants-plugins/blob/main/pants-plugins/experimental/ansible/deploy.py But as I think about it more, I realized in the
ansible
case,
deploy
only really meant "run this tool on these files/packages and it will magically provision a server or localhost", so
./pants run
on an
ansible_deployment
target could arguably work as well. Anyways, I got to the point where I'm not for or against anything on this, but I did reach a semantic existential crisis.
w

witty-family-13337

06/21/2022, 2:28 PM
that's a really good point, in the initial implementation we did at my company we called
install
as it correlated with
helm install
and it could fit well in case we wanted to instead a Go binary too (which would have a different behaviour for the
run goal
A run goal would in fact fit well with
helm_deployment
targets so now I falling into the same semantic crisis. Think the key difference is the ability to trigger the
publish
goal for the deployment dependencies, but not sure that's a general enough case worth pursuing.
👍 1
w

witty-crayon-22786

06/21/2022, 6:50 PM
“it could be part of `run`” is an argument against a lot of side-effecting goals, including
publish
. but i think that an argument can still be made that unifying a few different semantically similar implementations (ansible + helm, for example) behind a dedicated goal will frequently make sense, primarily because it encourages consistency: 1. if the answer to “how do i publish/deploy” is “write a
${lang}_binary
target with particular arguments and then use
run
on it”, then there isn’t necessarily anything encouraging consistency across the implementation of those binary targets. 2. from a type safety perspective, if
run
usually means running user code, it’s odd for
run
to do something else entirely for ansible/helm (because it means that even if you have empty input files, something might happen). but yea: worth being cautious: thanks for the proposal! will read in the next few days.
👍 3
h

happy-kitchen-89482

06/21/2022, 9:13 PM
@witty-family-13337 can you give commenting permissions on the doc?
FWIW I think
deploy
makes sense as a standalone goal, not
run
, e.g., to avoid
./pants run ::
doing dangerous you didn't intend...
🤯 1
OK that won't work today, but let's say
./pants run path/to/thing.py
That command line does not adequately convey that you're about to change production!
deploy
does
w

wide-midnight-78598

06/21/2022, 9:34 PM
Good point, I keep forgetting about the
::
- definitely not what you want to casually run for side-effect laden goals!
c

careful-address-89803

06/22/2022, 3:43 AM
hey folks, adding to what SJ said, I don't think there's really a case where "run" is strictly necessary as a goal. For some tools, there's a need for publish and do-effects. For example, Helm can both publish charts to a repository or deploy them to a cluster. Helm, Ansible, and Terraform don't have 2 types of do-effect tasks which would require separate goals. Some tools sortof have that with a synthesis stage. For example: Azure Bicep can be synthesised to ARM templates which are also a useful resource in themselves. But maybe that is more appropriately a codegen/package target, the way compiled code is for JVM targets. OTOH, I agree with Benjy that we should be signaling that these actions are going to prod. (Although sometimes publish does that too; but publish also signals that!) Also, I think there are many other tasks which would appreciate a "deploy" goal more than a generic "run" goal. For example, the Python AWS Lambda and Python Google Cloud Function targets have a package goal, but not the ability to actually upload that to their runtime. For another example, I think "running" a simple Kubernetes manifest wouldn't make much sense until someone explains that it's because there isn't a deploy goal. So my opinion (FWIW) is that a "deploy" goal is not strictly necessary but would help usability.
w

witty-family-13337

06/23/2022, 7:10 AM
@happy-kitchen-89482 the document should now have commenting permissions. Sorry again.
h

happy-kitchen-89482

07/06/2022, 2:02 AM
Hey, so I think this is good to go forward on an experimental basis!
The helm post-render trick seems like the way to go
w

witty-family-13337

07/11/2022, 10:07 AM
hi Benjy, sorry for the recent radio silence, had some family issues and took some time off to deal with those
glad to know that the proposal looks like a sound approach, will polish the original PR and getting it read for review