web-dev-qa-db-fra.com

Impossible de pousser depuis gitlab-ci.yml

Avec mes collègues, nous travaillons sur une bibliothèque C++ qui devient de plus en plus importante chaque jour. Nous avons déjà créé des utilitaires d'intégration continue via le gitlab-ci.yml fichier qui nous a permis:

  • Créer et tester en mode débogage
  • Build & Test en mode Release
  • Effectuez des contrôles de sécurité comme des fuites de mémoire en utilisant Valgrind et vérifiez s'il y a un symbole clair dans notre bibliothèque que nous ne voulons pas à l'intérieur
  • Générer de la documentation

Toutes sortes de choses qui nous ont fait choisir GitLab!

Nous aimerions profiler l'ensemble de notre bibliothèque et pousser les repères dans un projet distinct. Nous avons déjà fait quelque chose comme pour la documentation en utilisant la méthode clé SSH mais nous aimerions éviter cela cette fois.

Nous avons essayé un script comme celui-ci:

test_ci_Push:
  tags:
    - linux
    - Shell
    - light
  stage: profiling
  allow_failure: false
  only:
    - new-benchmark-stage
  script:
    - git clone http://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.mycompany.home/developers/benchmarks.git &> /dev/null
    - cd benchmarks
    - touch test.dat
    - echo "This is a test" > test.dat
    - git config --global user.name "${GITLAB_USER_NAME}"
    - git config --global user.email "${GITLAB_USER_EMAIL}"
    - git add --all
    - git commit -m "GitLab Runner Push"
    - git Push http://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.mycompany.home/developers/benchmarks.git HEAD:master
    - cd ..

Nous avons également essayé une base git Push Origin master pour pousser nos fichiers mis à jour mais à chaque fois nous obtenons la même réponse:

remote: You are not allowed to upload code for this project.
fatal: unable to access 'http://gitlab-ci-token:[email protected]/developers/benchmarks.git/': The requested URL returned error: 403

Les deux projets sont sous le même site et j'ai le droit de pousser dans les deux. Où est-ce que je fais quelque chose de mal ici?

shellgitlab-cigitlab-ci-runner
15
baptiste

Le jeton ci gitlab ressemble plus à la clé de déploiement dans github.com, il n'a donc qu'un accès en lecture au référentiel. Pour réellement pousser, vous devrez générer un jeton d'accès personnel et l'utiliser à la place.

Vous devez d'abord générer le jeton comme indiqué ici dans la documentation de gitlab . Assurez-vous de vérifier à la fois l'utilisateur lu et les portées api. De plus, cela ne fonctionne que dans GitLab 8.15 et supérieur. Si vous utilisez une version plus ancienne et que vous ne souhaitez pas mettre à niveau, il existe une méthode alternative que je pourrais vous montrer mais elle est plus complexe et moins sécurisée.

Au final, votre gitlab-ci.yml devrait ressembler à ceci:

test_ci_Push:
  tags:
    - linux
    - Shell
    - light
  stage: profiling
  allow_failure: false
  only:
    - new-benchmark-stage
  script:
    - git clone http://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.mycompany.home/developers/benchmarks.git &> /dev/null
    - cd benchmarks
    - echo "This is a test" > test.dat
    - git config --global user.name "${GITLAB_USER_NAME}"
    - git config --global user.email "${GITLAB_USER_EMAIL}"
    - git add --all
    - git commit -m "GitLab Runner Push"
    - git Push http://${YOUR_USERNAME}:${PERSONAL_ACCESS_TOKEN}@gitlab.mycompany.home/developers/benchmarks.git HEAD:master
    - cd ..
26
Clive Makamara

Bien que les réponses précédentes soient plus ou moins fines, il existe quelques gotya importants.

  before_script:
    - git config --global user.name "${GITLAB_USER_NAME}"
    - git config --global user.email "${GITLAB_USER_EMAIL}"
  script:
    - <do things>
    - git Push "https://${GITLAB_USER_NAME}:${CI_GIT_TOKEN}@${CI_REPOSITORY_URL#*@}" "HEAD:${CI_COMMIT_TAG}"

D'une part, nous avons seulement besoin de définir le nom d'utilisateur/e-mail pour plaire à git.

Deuxièmement, l'avoir dans le script précédent, n'est pas super crucial, mais permet une réutilisation plus facile lors de l'extension.

Enfin, pousser https est `` bien '' mais comme nous n'utilisons pas de clé ssh stockée, nous devons éviter tout ce qui peut révéler le jeton. D'une part, bien que gitlab n'imprime pas le jeton dans cette commande, git nous informera avec plaisir que le nouveau amont est défini sur https: // nom d'utilisateur: thetokeninplaintexthere @ url Il y a donc votre jeton en texte brut , donc n'utilisez pas -u pour définir un amont.

De plus, ce n'est pas nécessaire, nous ne faisons qu'un seul Push.

De plus, lors de la détermination de l'URL, j'ai trouvé que l'utilisation de CI_REPOSITORY_URL existait pour être la solution la plus fiable (lors du déplacement de référentiels par exemple ou d'autres joyeusetés). Nous remplaçons donc simplement le nom d'utilisateur/jeton dans la chaîne URL.

2
oliver

Vous pouvez également fournir un utilisateur et un mot de passe (utilisateur avec accès en écriture) comme variables secrètes et les utiliser.

Exemple:

before_script:
 - git remote set-url Origin https://$GIT_CI_USER:[email protected]/$CI_PROJECT_PATH.git
 - git config --global user.email '[email protected]'
 - git config --global user.name 'MyUser'

Vous devez définir GIT_CI_USER et GIT_CI_PASS en tant que variables secrètes (vous pouvez toujours créer un utilisateur dédié à cet effet).

Avec cette configuration, vous pouvez normalement travailler avec git. J'utilise cette approche pour pousser les balises après la sortie (avec Axion Release Gradle Pluing - http://axion-release-plugin.readthedocs.io/en/latest/index.html )

Exemple de tâche de libération:

release:
  stage: release
  script:
    - git branch
    - gradle release -Prelease.disableChecks -Prelease.pushTagsOnly
    - git Push --tags
  only:
   - master
1
Przemek Nowak