Answers: <p>The way GitLab CI is supposed to work is that you have a <code>gitlab-ci.yml</code> 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.</p>
  <p>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.</p>
  <p>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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-06-18T09:44:20.223Z
Answers: 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.
Answers: monz777
Answers: CC BY-SA 4.0
Answers: 2021-06-18T09:47:58.443Z
Answers: 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.
Answers: monz777
Answers: CC BY-SA 4.0
Answers: 2021-06-18T15:27:07.227Z
Answers: 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.
Answers: selfagency
Answers: CC BY-SA 4.0
Answers: 2021-06-18T22:46:54.857Z
Answers: 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.
Answers: monz777
Answers: CC BY-SA 4.0
Answers: 2021-06-19T05:20:28.277Z
Answers: Ah, well that's good to know too!
Answers: selfagency
Answers: CC BY-SA 4.0
Answers: 2021-06-18T04:00:50.437Z
Answers: 2021-06-18T15:28:58.833Z
Answers: 2021-06-18T15:28:58.833Z
Answers: selfagency
Body: <p>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?</p>
  <p>PS. I'm starting jobs using GitLab's trigger API (<a href="https://docs.gitlab.com/ee/ci/triggers/" rel="nofollow noreferrer">https://docs.gitlab.com/ee/ci/triggers/</a>)</p>
  
Tags: <gitlab>
Title: GitLab CI Job branch not up to date with origin
UserDisplayName: monz777
ThreadText: # GitLab CI Job branch not up to date with origin
  
  (Asked by: username_0 on 2021-06-17)
  
  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/>)
  
  **Tags:** gitlab
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2021-06-18. Score: 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.
  
  > **Comments:**
  > **username_0**: 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.  
  > **username_0**: 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.  
  > **username_1**: 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.  
  > **username_0**: 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.  
  > **username_1**: Ah, well that's good to know too!  
  
  ---
  
  