Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Versions of other folders as environment variables to current build #119

Open
nirradi opened this issue Apr 24, 2019 · 4 comments
Open

Versions of other folders as environment variables to current build #119

nirradi opened this issue Apr 24, 2019 · 4 comments

Comments

@nirradi
Copy link

nirradi commented Apr 24, 2019

I find it necessary to know the name of the artifacts of dependencies when building a folder.

for example:
It could be convenient to use MBT_MODULE_VERSION for tagging all the artifacts, but when module B is built after module A, the build script no longer has access to MBT_MODULE_VERSION of module A.

The best plan I had was using something like

mbt describe branch $(git rev-parse --abbrev-ref HEAD) --json | jq .$1.Version | sed 's/"//g'

which uses jq to parse the json response of the current versions in this git branch.

What ideas for workarounds do you have? It would be convenient having environment variables like
MBT_{MODULE_NAME}_VERSION
for all the projects.

@buddhike
Copy link
Member

Sounds like a reasonable feature request. You are on the right track with describe, however That still does not give you an easy way to identify deps of a given module.

Are you able to share a bit more about your use case?

Thanks

@nirradi
Copy link
Author

nirradi commented Apr 24, 2019

I'm using docker to build artifacts, the image name (artifact) can simply be image_name:${MBT_MODULE_VERSION}, that works fine.

for a simple example, module parrot depends on module birb. When I change something in birb then running mbt build will trigger a build command in birb and a docker image named birb:somelonghash is created

since I've correctly added birb as a dependency in the parraot/.mbt.yml - the docker builld command is run in the parrot directory. Ideally I want the docker to start my parrot build from the bird image
so parrot/Dockerfile needs to look something like this

FROM _birb_:somelonghash
RUN ...
CP ....

but clearly I can't hardcode the long hash into the file since I'll have to change that file each time I commit a change to birb, so I need to do something like

FROM _birb_:{CURRENT_BIRB_VERSION}

and instead of simply running docker-compose build as my build script, I need to write a bash script:

CURRENT_BIRB_VERSION=$(mbt describe branch $(git rev-parse --abbrev-ref HEAD) --json | jq ._birb_.Version | sed 's/"//g'
)

docker-compose build

If I had access to MBT_BIRB_VERSION as an evironment variable always, I could have left

name: _parrot_
build: 
  default:
    cmd: 'docker-compose'
    args: ['build']

instead of adding a ./build.sh script to each folder that prepares the environment variable from the mbt describe command.

@buddhike
Copy link
Member

Thanks for providing more context @nirradi.

You should be able to create the environment your build needs before you execute mbt build with templating capabilities. To do that, create a template to provision all module versions in the environment

{{- range $mod := .Modules -}}
export MBT_{{$mod.Name}}_VERSION="{{$mod.Version}}"
{{end}}

Then you run mbt apply command to produce a file that you can source before you run mbt build.
This would save you from writing wrapper script in each module directory.

e.g.

mbt apply commit <sha> --to .env.tmpl --out build/.env
#ensure build directory is listed in .gitignore file
source build/.env
mbt build commit <sha>

You might also be able to use the same templating technique to generate docker-compose file on the fly. However, without intimate knowledge about what your pipeline, I cannot think of exact steps 😉.

@nirradi
Copy link
Author

nirradi commented Apr 28, 2019 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants