3 ms·
> I don't understand why there needs to be an execution graph. Conditional logic? Of course. You may have different requirements, but here's an example flow of
by drdaeman 8y ago
> I don't understand why there needs to be an execution graph. Conditional logic?
Of course. You may have different requirements, but here's an example flow of the one project I had worked on:
Lint --------------------
\
Build -+-- Tests (fast) --+-- Release --- Deploy
\ /
- Tests (slow) -
There are some extra rules like deploy and slow tests only running for release tag builds (vX.Y.Z) and lint being allowed to fail for branches with "wip-" prefix in their name.
Lint runs in parallel with build + test (multiple runners, on different machines, each having some concurrency). Different tests run in parallel so you have to wait a little less. Tests only run after build is ready. Release only runs if both lint and tests succeed. Deploy is after the release.
You can write this graph as a shell script, but this is not without downsides:
1. You need a DSL (a bunch of pre-defined shell functions or external commands) that control the individual jobs in a sane manner.
2. You can't just look at the script and draw the pipeline graph (so before the pipeline's ran CI/CD can't tell you what's going to happen next).
3. You can't guarantee that the plan will be the same if pipeline is re-ran again. With shell scripts, program output may change, even though all inputs are the same.
If all you need is to run a simple shell script, with no multi-machine parallelism and no fancy conditional logic - all of the YAML stuff is an overkill you don't need. Although I guess all you need is approximately this:
run-ci:
script:
- ./run-ci.sh
Which doesn't look like any large sacrifice to me.
> gitlab-ci does some ninja code escape mangling thing (turn on debugging output to see it in action). So in your log you continue to see 'echo id: $CI_BUILD_ID' instead of 'id: 123456'.
Not sure I've encountered this much, but yes, this probably makes things complex. I agree that this is can be a pain point.
> I have no idea why anyone would do that.
I'm not sure, but the probable rationale is likely that they didn't want secrets to leak. Variables are the place where you can store various secret information, like CI signing keys or remote server credentials. They probably didn't want to leak what happens with e.g. `curl --user "ci:$CI_DEPLOY_PASSWORD" "$CI_DEPLOY_URL"`.