Can someone please explain jobs in gitlab-ci.yml

How to Use GitLab
1

For one reason or another I’m under the impression that each build get it’s own workspace, and that each job you create works on the same workspace? It seems however this isn’t the case.

I’m finding for each job I define, any changes made in the previous job isn’t available.

I’ve created some jobs in my .yml file to do the following;

Job1 - run ‘composer update’ to install any dependencies for the project using composer
Job2 - run ‘phpunit’ to run any tests in the project
Job3 - cleanup any files not needed for the actual build
Job4 - upload all files to FTP using ncftp

The issue I seem to be having is that Job2 throws error because packages that should have been installed by composer don’t exist. I know that I can use ‘before-script’ to run composer before each job, but then I’m struggling to understand what the purpose of having multiple jobs is, surely you could just put everything under one job and be done with it.

I do apologise if this comes across as a bit basic, but this is something I’m struggling to find any clear documentation for online.

1 Like
2

I believe this is by design and also confused me. Personally, to get around this, I am just executing everything I need in a single job.

It looks to me like the addition of artifacts (see CI/CD YAML syntax reference | GitLab) is intended to solve this problem.

For instance, the below entry in a job will preserve the contents of the binaries folder, as well as the .config file.

my_initial_build_job:
    artifacts:
        paths:
            - binaries/
            - .config

The documentation also states “Note that artifacts from previous stages are passed by default.” So, it seems that jobs run in subsequent stages will have access to any artifacts declared in a previous stage. You can actually see this in use in the Gitlab-CE source code, where they use artifacts to preserve the ‘knapsack’ directory.

The problem I see with this approach is that the artifacts are permanent. There is a nice option to specify how long to keep them around. I suppose 1 day would be just fine, but what is missing is “expire at end of this build”.