Closed matrinox closed 7 years ago
Can you check on the build server whether there's _build/$stage/lib/carafe?
Does autocompleting for Carafe work locally?
Do you enumerate your dependent applications like before Elixir 1.4 maybe? Then you need to add carafe there.
Can you check on the build server whether there's _build/$stage/lib/carafe?
ls $BUILD_PATH/_build/staging/lib/carafe/
👍
Does autocompleting for Carafe work locally?
No... I have it in my deps but it's not loaded
Do you enumerate your dependent applications like before Elixir 1.4 maybe? Then you need to add carafe there.
I'm using Elixir 1.4.4 and OTP/20. I haven't don't that. Let me try that
I was able to get it to work by just typing Carafe.
and then autocompleting with tab. Then after that, Carafe
is in the autocomplete. Adding it to :applications
or :extra_applications
didn't change that behaviour.
Ok so you don't need to add it as a dependancy and the docs are correct. But what I did doesn't work on the deployed server so same problem. I'll try to deploy with the dependancies added
On a somewhat different topic, is carafe compatible with Capistrano rollbacks? I want to design this in such a way that it's similar to Capistrano deploys in ruby apps.
I have no experience with rollbacks, so I'm not going to implement that. However, PRs are always welcome.
Personally, I have been fine for years with just pushing forward ;)
Actually, I missed that you consistently wrote about Elixir.Carafe
. The reason you see that in the error message is that it comes from Erlang, where Elixir names are mangled to be namespaced like that.
More precisely, Carafe
is essentially syntactic sugar for :"Elixir.Carafe"
.
Did you manage to deploy? Or is carafe missing from the built release?
I tried Carafe
as well but you can do either, I'm pretty sure.
I ended up just writing our own that is closer to the normal Capistrano flow. By normal I mean keeps the deploy task and just adds hooks around that flow. If I learn anything about rollbacks, I'd be happy to contribute back. Thanks!
Sorry to hear that.
@matrinox Same error i got, has be resolved by adding included_applications: [:carafe]
to mix.exs
.
Thanks @aligo
This really shouldn't be necessary. Carafe should be automatically part of the release as soon as it is declared as a dep, provided elixir is able to infer applications correctly (https://sergiotapia.me/application-inference-in-elixir-1-4-ae9e43e90301?gi=7a4588b0d07e).
Things are a bit more twisted in the case of an umbrella, see https://hexdocs.pm/carafe/configurationusage.html#umbrella-project-deployments.
Umbrella has been a headache ever since we've used it.
Concerning https://github.com/schnittchen/carafe/blob/master/lib/capistrano/tasks/node.rake#L89.
What is the purpose of that? Is there another way of accomplishing this? The less that is included in the production app the better and I was able to create a version that didn't use it but I also have yet to test the reliability without it
@matrinox that line is simply waiting for the OTP app to be up. In case of an umbrella app, that would be the top app in the app dependency tree.
If you omit that you might be fine sometimes, but you will run into a race condition sooner or later.
Yes it's ugly, and I am thinking of moving it over into the elixir part of carafe one day. Before I do that, this code would not be part of a release build and hence not part of a production app.
Actually I think I was wrong in my last comment, it's not race conditions that are the problem. Sometimes the application won't boot up properly (when the top level supervisor terminates), and without this polling loop we would not notice this.
@schnittchen Couldn't we just ping it, with bin/#{script} ping
? Or does that sometimes give false or premature positives?
In case of a boot failure, there can be a short time when the node is up and pingeable.
Ping twice in a row with a 1 second sleep?
Note edeliver does something similar, albeit in a different way. https://github.com/edeliver/edeliver/blob/master/lib/edeliver/startup_progress.ex#L23
It looks like relying on ping is not a good idea. However, you are free to try other ways by "overwriting" the node:full_restart task. Let me know when that works for you for a fair number of deploys!
This is what I get:
I've replaced
node:full_restart
withnode:stop-if-running
andnode:start
instead. I've also includedcarafe
in my mix dependancies but it doesn't show up in the remote console when I try to autocompleteElixir.Carafe
. Any idea?