Fork me on GitHub
#tools-build
<
2023-01-20
>
jjttjj18:01:34

I'm wondering where to draw the line on what a "build" is in relation to using tools.build for doing stuff on the cloud that requires certain artifacts to exist on the cloud before being able to create some required resources. For example, if I have code for an aws lambda I want to deploy using cloudformation, the steps are: 1. Build the lambda source dir to get a jar file. 2. Upload the lambda jar to s3 3. Put the the url of that jar in s3 in my cloudformation json template 4. Upload the template json to s3 5. Use the template json url to create (deploy) as a cloudformation stack. Is it reasonable to use tools.build for all these steps? Or all but the last step, which seems more about "deploy" than "build", which will likely eventually necessitate stuff you want to do that is outside the scope of tools.build. Or is tools.build specifically about just turning your clojure code into jars and everything after step 1 probably doesn't belong in a build.clj file?

lukasz18:01:07

Normally you want your release process (CI) to orchestrate builds and deployments, mixing both in one is usually too complicated and has big blast radius (suddenly your build process needs to know how to access AWS)

jjttjj18:01:56

@U0JEFEZH6 That makes sense but would you say that's "all but step 5" or "only step 1" in the build.clj file?

lukasz18:01:35

I would only do step 1, what happens with that Jar later should be done outside of build.clj - then again, (wait for it) it depends on your team, security posture, who/what orchestrates deployments. If you're a one-man shop, it doesn't really matter if you do all 5 in build.clj

jjttjj18:01:22

Cool thanks! Working on a library that does all this stuff and just trying to make sure I have good baseline assumptions and rule out that it doesn't just belong as tools.build helper functions

borkdude19:01:33

build.clj is just a convention, you can put whatever you like in there that you call with clojure -T:build foobar - I think it's just a matter of what is convenient for you

seancorfield19:01:11

FWIW, we do the equivalent of steps 1-4 at work and step 5 is managed separately. We don't use Lambda/CloudFormation but we 1. build the jar 2. upload the jar to s3 3. put that s3 URL in a deploy file 4. upload that deploy file to some servers. Our build.clj is 400+ lines at this point and has stuff for everything relating to dev, test, build...

👍 2
jjttjj20:01:10

Good to know. (Yeah and I know it's all somewhat arbitrary, you're going to have to do all these things somewhere. Just collecting opinions on the scope of tools.build "theoretically" I guess.)

lukasz20:01:37

I only limit it to producing the ubejar, Docker/Make/GH Actions take over from there

👍 2