[SOLVED] Hung ion push (and filling disk) when target/ on classpath

Datomic Cloud
1

I followed this recommendation from Figwheel:

Because our output files are going to be placed in the target/public directory by default and we want them to be served as static assets by the webserver we will need to add the target directory (NOT target/public ) to our classpath.

Later, I tried to push my code via Ions. It seemed to hang. The only thing I saw in the output was the typical Maven dependency fetches. I waited ~30 minutes, then started to investigate CloudWatch logs etc. as recommended on this topic, but didn’t see anything. I also didn’t see either of the S3 directories mentioned by the Ions Reference created (s3://$(datomic-code-bucket)/datomic/libs and s3://$(datomic-code-bucket)/datomic/apps), like I expected on my first push.

I killed the push process and tried it again, thinking maybe I was just the unlucky victim of a weird network issue. Went to dinner. Came back. Still hung.

I noticed that I could push from the ion-starter repo, which led me down the path of isolating the relevant difference between that deps.edn and my deps.edn, and, as indicated above, it was the fact that I had “target” in my :paths vector.

When I did a du -sch target, it reported 90G. Yikes! I think Ions got into a loop trying to add its build output to the build.

As a workaround, I changed Figwheel’s settings to use a different directory that isn’t included in the :paths vector, then removed “target” from the vector. The push worked fine at that point.

I’m mentioning this here (1) in case it helps anybody, and (2) to provide to Datomic devs a (hopefully reasonable) deps.edn scenario that leads to a rather frustrating first-time experience of Ions, in the hopes that avoiding this issue would be an easy improvement to avoid others the same frustration I experienced. Cheers. :beer: