5

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

  • Please add the log – 030 Apr 2 '18 at 14:50
  • attached is the logs@030 – pandey Apr 2 '18 at 15:14
3

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
  • If you want to set the origin to a Gitlab access token use oauth2:${GITLAB_ACCESS_TOKEN} as basic auth. – Overbryd Oct 24 '18 at 10:04
  • 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. – Overbryd Oct 24 '18 at 10:05
  • 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. – Overbryd Oct 24 '18 at 10:28
1

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
  • 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 – Tensibai Apr 2 '18 at 18:42
  • Could be possible, but this is not shown in the log. @pandey Could you post the complete log? – 030 Apr 2 '18 at 18:51
  • @030 git commands are not working when i defined it in after script...do i need to create as job1 and job 2? – pandey Apr 3 '18 at 13:05
  • If git is installed in the docker image and the authentication succeeds then it should work. – 030 Apr 3 '18 at 14:27
  • @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. – Ken Williams Nov 12 '18 at 19:29
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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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