mdubourg001 / glci

🦊 Test your Gitlab CI Pipelines changes locally using Docker.
568 stars 17 forks source link

Running sourced script functions does not work #3

Open frwickst opened 3 years ago

frwickst commented 3 years ago

Say that you have the following file, scripts.sh with:

hello_world() {
    echo "Hello world!"
}

If I in the pipeline would be to do the following in my script or in my case before_script:

- source scripts.sh
- hello_word

Then I would expect "Hello world" to be echoed.

This is something that works as expected when running in a normal GitLab CI Runner, however in the case of glci I'm getting this:

sh: hello_world: not found

I'm guessing the the problem here is that you do something different from that the GitLab runner is doing. As it says sh here and not bash I do see why this is not working however. And you are running sh here it seems https://github.com/mdubourg001/glci/blob/fad06bae4278a4c0640d55e3b3b5f19d572fc8a6/dist/cli.min.js#L126

So this is something that GitLab clearly does differently than glci.

richard-melvin commented 3 years ago

Example has function say_hello and call hello_world; does it still not work if they match?

frwickst commented 3 years ago

Ah, that was just an example I wrote. I'll fix it to have the correct name in both places. This was not the actual code I'm running, which does work as expected on GitLabs on CI.

mdubourg001 commented 3 years ago

I just tried out and this indeed does not work as expected.

The difference between GitLab CI and glci is that glci runs a docker exec inside the container for each command of the script keyword, while GitLab CI most probably (guessing here, not sure) maintain a single interactive shell in the running container and runs commands one by one through it. While the GitLab CI way allows keeping sourced functions in the shell between commands, the glci way loses sourced functions between each execs.

So it's not a trivial change to do for glci, but I will try to POC the GitLab CI approach for glci.

A (temporary) workaround for this is to use a one-liner:

- source scripts.sh && hello_world 

Thanks for reporting this, I'll keep this thread updated when possible.