Clojurians
#clojars
<
2016-01-06
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

danielcompton02:01:29

I’m thinking of separating out the clojars site build from the deploy phase, especially as this is likely to be run when the officials clojars repo is down

danielcompton02:01:55

So the Clojars uberjar will get built (by the Clojars server?) and put on S3, and then any future ansible run will be able to pull it down without clojars needing to be up

danielcompton02:01:38

I ran into a humorous issue where i had set the hostname of the vagrant box to be http://clojars.org so it tried to look up itself to download dependencies when the box was bootstrapping

tcrawley02:01:51

hmm, yeah, I guess it is kind of odd that we we build clojars on clojars, requiring clojars

tcrawley02:01:31

we could also build the uberjar locally, then copy it to the server

tcrawley02:01:50

and have the build run the tests first

tcrawley02:01:56

as it does now

danielcompton02:01:17

yeah that would be good, but I think it might need to be a separate operation so that if clojars is down it can still be redeployed

tcrawley02:01:53

well, if we move the repo to block storage, the repo would still be available, as would the mirror

danielcompton02:01:47

Thinking about pricing for cloud storage, do you know how the request pattern works with Leiningen when looking for deps? My assumption is that it checks custom repos, Maven Central, then Clojars. I wonder if we pay for requests for resources that don’t exist?

danielcompton02:01:27

There won’t be much bandwidth, but there is a per request fee which might add up if there are lots of 404s?

tcrawley02:01:48

that's a good point - yeah, aether asks everyone for everything, so we get lots of 404s

tcrawley02:01:46

we should check to make sure providers don't charge for 404 requests

danielcompton03:01:12

> As our intent is to charge equitably for system resources used, we will be charging the owner of the bucket for 403s and 404s, since they consume system resources (as do all requests). Note that we will not be charging for requests which fail due to an Amazon S3 internal system error (all other requests will be billed).

tcrawley03:01:27

interesting

tcrawley03:01:11

that's an interesting read. I wonder if DNSimple has since added support for multiple providers?

tcrawley03:01:19

we'll see soon enough I guess