I'm new to GitLab CI and don't really understand how Git works within the Jobs. When I'm checking git status on the first running job it is always on detached head state. If I'm switching to another branch (for which job was triggered) and checking git status, it is not up to date with the origin. Pulling the changes, can lead to merge conflics (pull --ff-only or pull --rebase not always help). Can you please explain how to handle this, always being up to date with the triggered branch?

PS. I'm starting jobs using GitLab's trigger API (https://docs.gitlab.com/ee/ci/triggers/)

1 Answer 1


The way GitLab CI is supposed to work is that you have a gitlab-ci.yml file in your repo with pipeline instructions for what GitLab should do when your repo gets pushed or a pull request is submitted to your repo. The pipeline is specific to each branch and will execute only on the branch to which you've pushed changes unless you've configured it otherwise. You can have entirely different pipelines for different branches. You can also manually run the jobs from within GitLab or via API, as you've been doing, but the power of it is that it runs automatically in the background on every code push.

What GitLab does with your repo is that it spins up a Docker container, clones your repo into it, runs whatever instructions you've given it, and then takes the artifacts it's generated, such as a build or test result, and makes them available to the next step in the pipeline, which could be pushing it to your server or your test coverage tool.

From what you're describing, and please correct me if I'm wrong, but it sounds like you're using your pipeline to alter the actual contents of your repo itself. I'm not sure that's the best move. The point of the pipeline process is to run tests, builds, and deployments. You can use it to push a package to NPM, or upload fresh code to your web server, or check your code for vulnerabilities. But I wouldn't use it to actually change code in the repository directly because the unintended side effects could be disastrous.

  • Thank you for explanation! Basically, in my pipeline I have 6 stages: test, copy, generate, build, deploy, notify. Copy stage downloads all assets from GoogleDrive, then I'm passing those assets as artifacts to generate stage. On generate stage, I'm generating spritesheets from the images and then passing those to the build stage. After build is completed I want to commit and tag the branch for which pipeline was triggered and as build job starting on detached head, I'm creating new temp branch with it, committing and trying to merge it to the triggered branch.
    – monz777
    Jun 18, 2021 at 9:44
  • The problem there is that when I switch to the triggered branch it is not up to date with the origin, so I need to pull the changes and thus can run into merge conflict that not possible to resolve automatically.
    – monz777
    Jun 18, 2021 at 9:47
  • As I said, I wouldn't modify my repo within a pipeline precisely because you're going to run into such problems. In my opinion, the point of doing the build process is not to keep the artifacts in your repo, but to push the build artifacts out so that your repo itself stays lightweight and quickly cloneable.
    – selfagency
    Jun 18, 2021 at 15:27
  • Thank you, that is really worth to reconsider. Need to dive deeper into the best practices. Also found that if you go to Settings - CI/CD - General Pipelines, there are options for git strategy for pipelines and git shallow clone number. When I changed to git clone strategy and set shallow number to 0, now branches up to date with origin on each run.
    – monz777
    Jun 18, 2021 at 22:46
  • Ah, well that's good to know too!
    – selfagency
    Jun 19, 2021 at 5:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.