Influence imports

[schuhwerk]

Hi! It's really nice, when you have an idea about a tool and actually find, that somebody already created it 😄 Thank you!

I'm not sure if this is the right place to ask (so I don't expect an answer and you can just close this issue).

I currently work with a structure like this:

• some_software
  • environment1
    • task1 (like ssh)
    • task2 (merge some url params)
    • task3 (open database)
    • ...
  • environment2
    • task1 (same as above) ..
  • ....

I use some_software in different environments. They all have the same (or mostly the same) tasks, where only basics like urls need replacement. So it makes most sense (to me ;) to use the same tasks.yml for all environments, and pass different environment-variables to them.

So i tried the following:

#.ahoy.yml
commands:
  some_software:
    usage: List the commands from the imported config files.
    imports:
    - ./environment1.yml #<-- this imports tasks.yml
    - ./environment2.yml #<-- this also imports tasks.yml

#.environment1.yml
commands:
  environment1:
    usage: List tasks
    imports:
    - ./tasks.yml

#.tasks.yml
commands:
  task1:
    usage: Use env defined in parent
    cmd: echo "$SOME_ENVIRONMENT_VARIABLE followed by parameters $1"

I learned, that entrypoint is only executed, when there is actual commands (not for imports) and there can not be a cmd and import at the same time. So I don't know how to "define something" in environment1.yml. This might be related to https://github.com/ahoy-cli/ahoy/issues/21. Do you have any idea, how I could achieve this? Did I miss something?

A solution could be executing ahoy from subfolders (that contain files with environment-variables) and referencing the task.yml in a parent folder. As root stays the same (ls -la always shows the folder where you started ahoy), including the environment-variables in entrypoint in tasks.yml whould include the environment-variables from the subfolders. This takes away some of the "simplicity" though.

[frankcarey]

Hi! It's really nice, when you have an idea about a tool and actually find, that somebody already created it 😄 Thank you!

For sure! Thank you for being a supporter! Just seeing this now, but let me think on it a bit and check examples of what I've done in my own projects for that type of thing and get back to you soon hopefully.

[frankcarey]

Quick thought now - A common thing I do at least is call ahoy from ahoy. The script is very lightweight and fast, so I will do things where instead of using imports, I write some bash in one command to call ahoy -f some-commands.yaml $@ to pass along the params from the "parent" ahoy call to "children", meaning you don't have to use the imports at all. Downside is you do have to have one command in place like I think you are saying, but I haven't found that to be an issue too often. Definitely let me know if that solution works for you or how it could be better!

[hanoii]

I am curious on why you'd need to pass on environment variables, being that environment variables are already exactly that. The use case you are referring to as having to replace urls and stuff per environment is simply making sure those environment variables are available before calling the ahoy command, or am I missing something?

[schuhwerk]

Thanks for your ideas! They work nicely together 🥳

#.ahoy.yml
ahoyapi: v2
commands:
  env-1:
    usage: Commands for E1.
    cmd: export $(grep -v '^#' 1.env | xargs) && ahoy -f tasks.ahoy.yml $@
  env-2:
    usage: Commands for E2.
    cmd: export $(grep -v '^#' 2.env | xargs) && ahoy -f tasks.ahoy.yml $@

#tasks.ahoy.yml
ahoyapi: v2
commands:
  test-command:
    usage: An example of a single-line command.
    cmd: echo "Do stuff with $NAME"

#1.env
NAME="Env-1"

#2.env
NAME="Env-2"

Running ahoy env-X test-command returns "Do stuff with Env-X". That's good enough for me (so you can close the issue, if you want :)