Answers: <p>Combining the answer of <a href="https://devops.stackexchange.com/a/3854/10932">https://devops.stackexchange.com/a/3854/10932</a> and the comment of Overbryd along with a slight modification worked for me. Here, instead of using using <strong>git remote set-url</strong> command, I used <strong>git remote add</strong>.</p>
  <p>The code will look like this:</p>
  <pre><code>image: maven
  
  stages:
  - build
  - deploy
  - tag
  
  maven_build:
  stage: build
  
    script:
     - mvn clean package
     artifacts:
    paths:
     - target/*.jar
  
    after_script:
     - ls -a
     - cd target &amp;&amp; ls -a
     - git --version
     - git remote remove origin
     - git remote add origin https://&quot;username:passwd&quot;@gitlab.com/accountname/projectname.git
     - git config user.email &quot;${GITLAB_USER_EMAIL}&quot;
     - git config user.name &quot;${GITLAB_USER_NAME}&quot;
     - git tag -a 1.0.15 -m &quot;Version created by gitlab-ci Build&quot;
     - git push origin 1.0.15
    only:
      - master
  </code></pre>
  <p>Thanks to both.</p>
  
Answers: CC BY-SA 4.0
Answers: 2020-10-02T19:23:44.940Z
Answers: We can also use Gitlab personal access tokens instead of directly using Gitlab's username and password. 
  Link: https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html
Answers: Neron Joseph
Answers: CC BY-SA 4.0
Answers: 2020-09-21T04:47:10.360Z
Answers: 2020-09-21T04:47:10.360Z
Answers: Neron Joseph
Answers: <p><code>git push origin 1.0.15</code> should work and a new tag should be added to the tags in gitlab</p>
  
  <p><a href="https://docs.gitlab.com/ee/university/training/topics/tags.html" rel="nofollow noreferrer">https://docs.gitlab.com/ee/university/training/topics/tags.html</a></p>
  
  <blockquote>
  <pre><code>git checkout master
  
  # Lightweight tag
  git tag my_lightweight_tag
  
  # Annotated tag
  git tag -a v1.0 -m ‘Version 1.0’
  git tag
  
  git push origin --tags
  </code></pre>
  </blockquote>
  
Answers: CC BY-SA 3.0
Answers: 2018-04-02T18:42:56.217Z
Answers: I think the runner get only a read key to clone the repo, the runner won't be able to push back on the repo IIRC
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2018-04-02T18:51:44.830Z
Answers: Could be possible, but this is not shown in the log. @pandey Could you post the complete log?
Answers: 030
Answers: CC BY-SA 3.0
Answers: 2018-04-03T13:05:18.263Z
Answers: @030 git commands are  not working when i defined it in after script...do i need to create as job1 and job 2?
Answers: pandey
Answers: CC BY-SA 3.0
Answers: 2018-04-03T14:27:32.710Z
Answers: If git is installed in the docker image and the authentication succeeds then it should work.
Answers: 030
Answers: CC BY-SA 4.0
Answers: 2018-11-12T19:29:35.513Z
Answers: @030 This won't generally work, the runner indeed typically only has read-only access to the repository.  The error in the logs looks like: `$ git push origin --tags
  \nremote: You are not allowed to upload code.`
Answers: Ken Williams
Answers: CC BY-SA 3.0
Answers: 2018-04-02T18:29:51.587Z
Answers: 2018-04-02T18:29:51.587Z
Answers: 030
Answers: <p>If you prefer ssh connection use this:</p>
  <pre><code>after_script:
    - git --version
    - git remote remove origin
    - git remote add origin git@gitlab.com:$CI_PROJECT_PATH.git
    - git tag -a v-$CI_COMMIT_SHORT_SHA -m &quot;Version created by gitlab-ci Build&quot;
    - git push --tags
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2021-05-14T00:50:38.067Z
Answers: 2021-05-14T00:50:38.067Z
Answers: Maycon Ritzmann
Answers: <p>I find myself in the same situation, where after publishing a build of an artifact, I want to tag the commit with a version number tag.</p>
  
  <p>One solution I'm considering is to create a service (either inside or outside of GitLab) that's capable of pushing a tag to any repository, but <strong>can't do anything else</strong>.  The service itself would possess credentials allowing it to write to repositories, so that each project build doesn't need to be granted write access to the repo.</p>
  
  <p>I like this solution because GitLab doesn't seem to offer a permission level that can push tags onto existing commits, without also granting the ability to push commits containing new content.  Generic write access is more permission than we need or want for this use case, so if we had it, we'd probably need to limit the scope by creating a user or a token <em>for each repository</em> with permissions to commit to just that repository.  Then we'd need to manage all those users or tokens over time, which seems like it could get unwieldy.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-11-12T19:30:34.537Z
Answers: 2018-11-12T19:30:34.537Z
Answers: Ken Williams
Answers: <p>I tried to change docker image and added couple steps for git tag. Below is the answer worked for me,</p>
  
  <pre><code>image: maven
  
  stages:
  - build
  - deploy
  - tag
  
  maven_build:
  stage: build
  
    script:
     - mvn clean package
     artifacts:
    paths:
     - target/*.jar
  
    after_script:
     - ls -a
     - cd target &amp;&amp; ls -a
     - git --version
     - git remote remove origin
     - git remote set-url origin https://"username:passwd"@gitlab.com/accountname/projectname
     - git tag -a 1.0.15 -m "Version created by gitlab-ci Build"
     - git push origin 1.0.15
    only:
      - master
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2018-10-24T10:04:29.573Z
Answers: If you want to set the origin to a Gitlab access token use `oauth2:${GITLAB_ACCESS_TOKEN}` as basic auth.
Answers: Overbryd
Answers: CC BY-SA 4.0
Answers: 2018-10-24T10:05:56.513Z
Answers: Also I would like to note, that you do not need to remove the `origin`, you can just `git remote add api-origin https://...` that shaves off one line. Later use that new origin in `git push api-origin 1.0.15`.
Answers: Overbryd
Answers: CC BY-SA 4.0
Answers: 2018-10-24T10:28:55.493Z
Answers: And I needed to add two lines, `git config user.email "${GITLAB_USER_EMAIL}"` and `git config user.name "${GITLAB_USER_NAME}"` to get it to push nicely.
Answers: Overbryd
Answers: CC BY-SA 4.0
Answers: 2019-04-12T08:58:17.280Z
Answers: you can also skip a job/pipeline execution adding `-o ci.skip` in your git push command
Answers: Nicolas Pepinster
Answers: CC BY-SA 4.0
Answers: 2021-08-26T08:59:02.397Z
Answers: This is problematic as it puts username/password in a source repository... unsafe for obvious reasons, and outright forbidden if you work for security-aware customers or companies.
Answers: AnoE
Answers: CC BY-SA 4.0
Answers: 2021-11-08T16:08:55.417Z
Answers: How can we create tags in gitlab from Jenkins Pipeline after successful builds @pandey
Answers: Manikandan Ram
Answers: CC BY-SA 3.0
Answers: 2018-04-10T13:35:25.287Z
Answers: 2018-04-10T13:35:25.287Z
Answers: pandey
Body: <p>We got gitlab new to our environment and trying to create some CI CD pipelines using gitlab CI. I have got some better progress with running some maven goals, creating pipelines and archiving artifacts using my .gitlab-ci.yml as below. I tried to give give tags after script which doesnt work. Now, I am trying to figure out how can I automate git tags to my sourcecode. I would like to create tag for sourcecode after master branch got successful build. we are using Semantic versions to tag our source code. Finally, so whenever master got successful build I would like to create a tag to my master branch.</p>
  
  <pre><code>image: maven:3.5-jdk-8-alpine
  
  stages:
   - build
   - deploy
   - tag
  
  maven_build:
    stage: build
  
    script:
     - mvn clean package
  artifacts:
   paths:
   - target/*.jar
  
  after_script:
     - ls -a
     - cd target &amp;&amp; ls -a
     - git --version
     - git tag -a 1.0.15 -m "Version created by gitlab-ci Build"
     - git push origin 1.0.15
  only:
    - master
  </code></pre>
  
  <p>logs:</p>
  
  <pre><code>Running after script...
  $ ls -a
  .
  ..
  .git
  .gitignore
  .gitlab-ci.yml
   LICENSE
  README.md
  pom.xml
  src
  target
  $ cd target &amp;&amp; ls -a
  .
  ..
  apidocs
  classes
  generated-sources
  generated-test-sources
  javadoc-bundle-options
  maven-archiver
  maven-simple-0.2-SNAPSHOT-javadoc.jar
  maven-simple-0.2-SNAPSHOT-sources.jar
  maven-simple-0.2-SNAPSHOT.jar
  maven-status
  surefire-reports
  test-classes
  Uploading artifacts...
  target/maven-simple-0.2-SNAPSHOT-javadoc.jar: found 1 matching files 
  Uploading artifacts to coordinator... ok            id=60598296 
  responseStatus=201 Created token=Gu-eH1es
  </code></pre>
  
  <p>Job succeeded</p>
  
Comments: CC BY-SA 3.0
Comments: 2018-04-02T14:50:52.960Z
Comments: Please add the log
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2018-04-02T15:14:04.877Z
Comments: attached is the logs@030
Comments: pandey
Tags: <continuous-integration><gitlab><gitlab-ci-runner>
Title: How to tag source code using gitlabCI
UserDisplayName: pandey
ThreadText: # How to tag source code using gitlabCI
  
  (Asked by: username_0 on 2018-04-02)
  
  We got gitlab new to our environment and trying to create some CI CD pipelines using gitlab CI. I have got some better progress with running some maven goals, creating pipelines and archiving artifacts using my .gitlab-ci.yml as below. I tried to give give tags after script which doesnt work. Now, I am trying to figure out how can I automate git tags to my sourcecode. I would like to create tag for sourcecode after master branch got successful build. we are using Semantic versions to tag our source code. Finally, so whenever master got successful build I would like to create a tag to my master branch.
  
  ```
  image: maven:3.5-jdk-8-alpine
  
  stages:
   - build
   - deploy
   - tag
  
  maven_build:
    stage: build
  
    script:
     - mvn clean package
  artifacts:
   paths:
   - target/*.jar
  
  after_script:
     - ls -a
     - cd target && ls -a
     - git --version
     - git tag -a 1.0.15 -m "Version created by gitlab-ci Build"
     - git push origin 1.0.15
  only:
    - master
  
  ```
  
  logs:
  
  ```
  Running after script...
  $ ls -a
  .
  ..
  .git
  .gitignore
  .gitlab-ci.yml
   LICENSE
  README.md
  pom.xml
  src
  target
  $ cd target && ls -a
  .
  ..
  apidocs
  classes
  generated-sources
  generated-test-sources
  javadoc-bundle-options
  maven-archiver
  maven-simple-0.2-SNAPSHOT-javadoc.jar
  maven-simple-0.2-SNAPSHOT-sources.jar
  maven-simple-0.2-SNAPSHOT.jar
  maven-status
  surefire-reports
  test-classes
  Uploading artifacts...
  target/maven-simple-0.2-SNAPSHOT-javadoc.jar: found 1 matching files 
  Uploading artifacts to coordinator... ok            id=60598296 
  responseStatus=201 Created token=Gu-eH1es
  
  ```
  
  Job succeeded
  
  **Tags:** continuous-integration, gitlab, gitlab-ci-runner
  
  > **Comments:**
  > **username_1**: Please add the log  
  > **username_0**: attached is the logs@username_1  
  
  ---
  
  ## 5 answers
  
  ### Answer by username_0 on 2018-04-10. Score: 13 | Accepted answer
  
  I tried to change docker image and added couple steps for git tag. Below is the answer worked for me,
  
  ```
  image: maven
  
  stages:
  - build
  - deploy
  - tag
  
  maven_build:
  stage: build
  
    script:
     - mvn clean package
     artifacts:
    paths:
     - target/*.jar
  
    after_script:
     - ls -a
     - cd target && ls -a
     - git --version
     - git remote remove origin
     - git remote set-url origin https://"username:passwd"@gitlab.com/accountname/projectname
     - git tag -a 1.0.15 -m "Version created by gitlab-ci Build"
     - git push origin 1.0.15
    only:
      - master
  
  ```
  
  > **Comments:**
  > **username_6**: If you want to set the origin to a Gitlab access token use `oauth2:${GITLAB_ACCESS_TOKEN}` as basic auth.  
  > **username_6**: Also I would like to note, that you do not need to remove the `origin`, you can just `git remote add api-origin https://...` that shaves off one line. Later use that new origin in `git push api-origin 1.0.15`.  
  > **username_6**: And I needed to add two lines, `git config user.email "${GITLAB_USER_EMAIL}"` and `git config user.name "${GITLAB_USER_NAME}"` to get it to push nicely.  
  > **username_7**: you can also skip a job/pipeline execution adding `-o ci.skip` in your git push command  
  > **username_8**: This is problematic as it puts username/password in a source repository... unsafe for obvious reasons, and outright forbidden if you work for security-aware customers or companies.  
  > **username_9**: How can we create tags in gitlab from Jenkins Pipeline after successful builds @username_0  
  
  ---
  
  ### Answer by username_2 on 2020-09-21. Score: 3
  
  Combining the answer of <https://devops.stackexchange.com/a/3854/10932> and the comment of username_6 along with a slight modification worked for me. Here, instead of using using **git remote set-url** command, I used **git remote add**.
  
  The code will look like this:
  
  ```
  image: maven
  
  stages:
  - build
  - deploy
  - tag
  
  maven_build:
  stage: build
  
    script:
     - mvn clean package
     artifacts:
    paths:
     - target/*.jar
  
    after_script:
     - ls -a
     - cd target && ls -a
     - git --version
     - git remote remove origin
     - git remote add origin https://"username:passwd"@gitlab.com/accountname/projectname.git
     - git config user.email "${GITLAB_USER_EMAIL}"
     - git config user.name "${GITLAB_USER_NAME}"
     - git tag -a 1.0.15 -m "Version created by gitlab-ci Build"
     - git push origin 1.0.15
    only:
      - master
  
  ```
  
  Thanks to both.
  
  > **Comments:**
  > **username_2**: We can also use Gitlab personal access tokens instead of directly using Gitlab's username and password.  Link: https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html  
  
  ---
  
  ### Answer by username_1 on 2018-04-02. Score: 2
  
  `git push origin 1.0.15` should work and a new tag should be added to the tags in gitlab
  
  <https://docs.gitlab.com/ee/university/training/topics/tags.html>
  
  > ```
  > git checkout master
  >
  > # Lightweight tag
  > git tag my_lightweight_tag
  >
  > # Annotated tag
  > git tag -a v1.0 -m ‘Version 1.0’
  > git tag
  >
  > git push origin --tags
  >
  > ```
  
  > **Comments:**
  > **username_3**: I think the runner get only a read key to clone the repo, the runner won't be able to push back on the repo IIRC  
  > **username_1**: Could be possible, but this is not shown in the log. @username_0 Could you post the complete log?  
  > **username_0**: @username_1 git commands are  not working when i defined it in after script...do i need to create as job1 and job 2?  
  > **username_1**: If git is installed in the docker image and the authentication succeeds then it should work.  
  > **username_4**: @username_1 This won't generally work, the runner indeed typically only has read-only access to the repository.  The error in the logs looks like: `$ git push origin --tags \nremote: You are not allowed to upload code.`  
  
  ---
  
  ### Answer by username_5 on 2021-05-14. Score: 1
  
  If you prefer ssh connection use this:
  
  ```
  after_script:
    - git --version
    - git remote remove origin
    - git remote add origin git@gitlab.com:$CI_PROJECT_PATH.git
    - git tag -a v-$CI_COMMIT_SHORT_SHA -m "Version created by gitlab-ci Build"
    - git push --tags
  
  ```
  
  
  ---
  
  ### Answer by username_4 on 2018-11-12. Score: 0
  
  I find myself in the same situation, where after publishing a build of an artifact, I want to tag the commit with a version number tag.
  
  One solution I'm considering is to create a service (either inside or outside of GitLab) that's capable of pushing a tag to any repository, but **can't do anything else**. The service itself would possess credentials allowing it to write to repositories, so that each project build doesn't need to be granted write access to the repo.
  
  I like this solution because GitLab doesn't seem to offer a permission level that can push tags onto existing commits, without also granting the ability to push commits containing new content. Generic write access is more permission than we need or want for this use case, so if we had it, we'd probably need to limit the scope by creating a user or a token *for each repository* with permissions to commit to just that repository. Then we'd need to manage all those users or tokens over time, which seems like it could get unwieldy.
  
  
  ---
  
  