Support storing variable via yaml file

[marcinkuzminski]

Description

Here's our use case, we keep certain versions inside the source code of bashly generated script. This is mostly used when we do a self-update call that does downloads new script, and does comparison on internal changes and components our script is installing.

Similar how version works and it's available globally in the script.

Our workaround is to keep thi in the initialize.sh, but it would be nicer if we bump version and all internal versions of components from yaml file.

my idea was a new section called variables that would keep them in it's own namespace so it doesn't get mixed with any other script defined vars.

variables:
 - foo: bar

What do you think about such feature ?

[DannyBen]

I am not sure I am following.
Are you talking about internal variables that your script needs?

If so, what is wrong with having this setup:

# src/initialize.sh
load_vars

# src/lib/load_vars.sh
load_vars() {
  git_version=1.2.3
  docker_version=4.5.6
}

Isn't this clean enough?
How would you imagine this variables section in the YAML affect the generated script?

[DannyBen]

BTW - since you mentioned internal components, I am not sure if you are familiar with the Extensible Scripts feature in bashly, which lets you develop standalone scripts that work together (like developing a separate script for "docker pull" and "docker build").

Just wanted to mention it in case it is relevant.

[DannyBen]

@marcinkuzminski do you still need help with this / wish to discuss this further?

[DannyBen]

I am closing this. If there is any interest in continuing the discussion, we can reopen.

[DannyBen]

This is now available in master branch and will be added to the next release.

[DannyBen]

Since there was more demand for the variables section (#562), this is now available in v1.2.4.

[marcinkuzminski]

Thank you for implementing this feature! It will help us greatly.

[DannyBen]

Docs: Configuration / Variable

[marcinkuzminski]

Hi Again :)

I have a question: is there any specific reason the global variables are set after initialize part?

Based on what i've seen on generated scripts

initialize
run "$@" #<-- here is where globals are initialized

We have a bunch of code in initialize script that we want to read from the global variables. This chain of actions makes it unavailable there.