Lucky before boot sequence

[jwoertink]

After having just setup my machine from a fresh wipe, I noticed I was missing a few things. This made me think of something I think would be awesome.

Imagine you have an app that requires redis, postgres, elasticsearch, and docker all to be running in order for your app to work. Right now, if none of this is installed, your app might not know until it hits a point where it needs one of these. That could be deep in your app, or in a section that maybe you haven't touched in a bit.

What if we had some yaml file in our config that, if it exists, would run a pre-boot sequence. This could be all up to you to decide, but in my case, it might look something like this:

on_boot:
  - ./script/check_elasticsearch_running
  - ps aux | grep redis | wc -l  ..... you get the idea
  - echo "whatever"
  - lucky db.verify_connection

With this, I can put as many arbitrary calls as I'd like. Maybe there's a crystal config that says if this should run in development only, or maybe an option that says use boot.yml by default, but in staging you can use boot.staging.yml instead...

Then all Lucky does is says "does this yaml exist? ok, parse it, and run the on_boot sequence stuff before booting".

I'm also open to other ideas on how we can best solve this. The main idea here is before I boot my Lucky app, I want something that tells me which things aren't running that need to be. This also allows me to not have all these services running on my machine all the time. I can boot them as I need them, and then stop them and not worry about forgetting.

[jwoertink]

On a slightly side note, we currently have this config/watch.yml which doesn't contain much, and has a few issues. What if that became config/config.yml, and then it had a watch section, and this on_boot went in to that file? I'm a fan of having less files to worry about. It could also potentially contain other config stuff that's not exactly a crystal code config type deal.... or, do we just make it all crystal and get rid of yml loading?

[paulcsmith]

I like this idea a lot. I'd love to make this as flexible and dirt simple as possible. Here's a quick solution I came up with that works right now and could be added super easily

Use Procfile.dev and a shell script

# Procfile.dev
system_check: script/system_check

Then add your shell script and do whatever you want! exit with non-zero and it'll stop the app from starting

#!/bin/bash
# script/system_check

BOLD_RED_COLOR="\e[1m\e[31m"

print_error() {
    printf "${BOLD_RED_COLOR}There is a problem with your system setup:\n\n   ${BOLD_RED_COLOR}$1 \n\n"
    exit 1
}

print_error "Elasticsearch is not running. Run it with some_command

# If we don't raise an error, return $SHELL so the process still runs and lets the process runner continue booting the other processes
$SHELL

This is dead simple and flexible. It won't run checks for other commands like lucky db.migrate or something. I think that's fine though.

What do you think?

[paulcsmith]

We could add this to Lucky CLI super easily. I'm guessing by default it just checks the db connection and maybe something like checking that Crystal is installed (though that'll be added in the Crystal version checker I'm working on later)

[jwoertink]

Oh yeah! That's pretty nice. I think making it as simple and flexible as possible is the key. That's a lot cleaner than I was thinking. We just add that to the CLI with a simple db check or whatever, then just document what you can do with it, and that would be great!

[jwoertink]

I started looking at this, and maybe found a crystal bug. It turns out calling lucky db.verify_connection has no way to tell if it failed or not from bash. It will always return a exit status of 0. This is caused from https://github.com/luckyframework/lucky_cli/blob/master/src/lucky.cr#L48-L54

crystal-lang/crystal#8381