Como marcar o código-fonte usando o gitlabCI

Temos o gitlab novo em nosso ambiente e tentamos criar alguns pipelines de CD do CI usando o gitlab CI. Eu tenho um progresso melhor na execução de alguns objetivos, criando pipelines e arquivando artefatos usando meu .gitlab-ci.yml como abaixo. Eu tentei dar tags após o script que não funciona. Agora, estou tentando descobrir como automatizar as tags git no meu código-fonte. Eu gostaria de criar uma tag para código fonte depois que o ramo principal obteve uma compilação bem-sucedida. estamos usando versões semânticas para marcar nosso código-fonte. Finalmente, sempre que o master obtiver êxito na compilação, eu gostaria de criar uma tag no meu branch master.

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

Histórico:

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

Trabalho bem sucedido

continuous-integration gitlab gitlab-ci-runner

— pandey
fonte

Por favor, adicione o log

— 030

anexado é os logs @ 030

— pandey

Respostas:

Tentei alterar a imagem do docker e adicionei algumas etapas para a tag git. Abaixo está a resposta que funcionou para mim,

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

— pandey
fonte

Se você deseja definir a origem como um token de acesso do Gitlab, use oauth2:${GITLAB_ACCESS_TOKEN}como autenticação básica.

— Overbryd

Também gostaria de observar que você não precisa remover o origin, você pode apenas git remote add api-origin https://...isso raspar uma linha. Mais tarde, use essa nova origem em git push api-origin 1.0.15.

— Overbryd

E eu precisava adicionar duas linhas, git config user.email "${GITLAB_USER_EMAIL}"e git config user.name "${GITLAB_USER_NAME}"fazê-lo funcionar bem.

— Overbryd

você também pode pular uma execução de tarefa / gasoduto adicionando -o ci.skipem seu comando git empurrar

— Nicolas Pepinster

git push origin 1.0.15 deve funcionar e uma nova tag deve ser adicionada às tags no 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

— 030
fonte

Eu acho que o corredor de obter apenas uma chave de leitura para clonar o repo, o corredor não será capaz de empurrar para trás na IIRC repo

— Tensibai

Pode ser possível, mas isso não é mostrado no log. @pandey Você poderia postar o log completo?

— 030

@ 030 Os comandos git não estão funcionando quando eu o defini após o script ... preciso criar como job1 e job 2?

— Pandey #

Se o git estiver instalado na imagem do docker e a autenticação for bem-sucedida, ele deverá funcionar.

— 030

@ 030 Geralmente, isso não funciona, o corredor normalmente só tem acesso somente de leitura ao repositório. O erro nos logs parece:$ git push origin --tags \nremote: You are not allowed to upload code.

— Ken Williams

Eu me encontro na mesma situação, onde, após publicar uma construção de um artefato, desejo marcar o commit com um tag de número de versão.

Uma solução que estou considerando é criar um serviço (dentro ou fora do GitLab) capaz de enviar uma tag para qualquer repositório, mas não pode fazer mais nada . O serviço em si possuiria credenciais permitindo gravar nos repositórios, para que cada construção do projeto não precise ter acesso de gravação ao repositório.

Eu gosto dessa solução porque o GitLab parece não oferecer um nível de permissão que pode enviar tags para confirmações existentes, sem também conceder a capacidade de enviar confirmações que contenham novo conteúdo. O acesso de gravação genérico é mais permissão do que precisamos ou queremos para este caso de uso; portanto, se o tivéssemos, provavelmente precisaríamos limitar o escopo criando um usuário ou um token para cada repositório com permissões para confirmar apenas esse repositório. Em seguida, precisaríamos gerenciar todos esses usuários ou tokens ao longo do tempo, o que parece ser difícil de manejar.

— Ken Williams
fonte