[JAVA] Remarques sur la migration de CircleCI 1.0 vers 2.0

Obtenez un aperçu sur cette page http://tech.smarthr.jp/entry/2017/07/12/073000

Documentation officielle de la procédure de migration https://circleci.com/docs/2.0/migrating-from-1-2/

Documents utilisant le point de terminaison config-translation https://circleci.com/docs/2.0/config-translation/

Utilisez config-translation Endpoint pour obtenir le fichier de configuration.

Supposons que la page de construction dans CircleCI soit l'URL suivante:

https://circleci.com/gh/:username/:project

Dans le cas ci-dessus, le point de terminaison config-translation serait une URL comme celle-ci: Ici, la branche est spécifiée comme «develop».

https://circleci.com/api/v1.1/project/github/:username/:project/config-translation?branch=develop

Le fichier est téléchargé avec le nom de fichier config-translation.

Modèle NG J'ai défini le nom d'utilisateur de mon compte GitHub sur : username, et le résultat de réponse suivant a été obtenu.

{
  "message" : "{\"message\":\"Not Found\",\"documentation_url\":\"https://developer.github.com/v3/repos/#get\"}"
}

Incorporez le fichier de configuration téléchargé dans le projet.

Reportez-vous à ce qui suit https://circleci.com/docs/2.0/migrating-from-1-2/

Créez un dossier .circleci à la racine du projet, déplacez-y le fichier de configuration téléchargé et renommez le fichier en config.yml.

$ mkdir .circleci
$ mv /hoge/config-translation .circleci/config.yml

Ajoutez la description de «Déploiement».

Il n'y a pas de description de Deployment dans le fichier de configuration téléchargé, vous devez donc l'écrire vous-même.

Une erreur se produit dans maven integration-test.

#!/bin/bash --login
mvn integration-test
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.104 s
[INFO] Finished at: 2018-04-09T04:25:24+00:00
[INFO] Final Memory: 15M/904M
[INFO] ------------------------------------------------------------------------
[ERROR] The goal you specified requires a project to execute but there is no POM in this directory (/home/ubuntu/topgate/hogehoge/server). Please verify you invoked Maven from the correct directory. -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MissingProjectException
Exited with code 1

On dit que pom.xml n'existe pas. pom.xml existe dans / server / pom.xml. Dans "1.0", la description suivante était correcte.

general:
  build_dir: server

Dans 2.0, il est converti comme suit, mais comme il est extrait dans working_directory, il est changé en ~ / topgate / hogehoge / server / server au lieu de ~ / topgate / hogehoge / server. , Pom.xml existait, et sans pom.xml, une erreur s'est produite.

version: 2
jobs:
  build:
    working_directory: ~/topgate/hogehoge/server

Je peux penser aux deux solutions suivantes. Proposition (1) Définissez working_directory: ~ / topgate / hogehoge / server / server comme option lors de l'exécution de la commande mvn.

    - run:
        working_directory: ~/topgate/hogehoge/server/server
        command: mvn dependency:go-offline || true

Proposition (2) Définissez path: ~ / topgate / hogehoge dans la commande d'extraction et spécifiez le dossier de niveau supérieur suivant.

    - checkout:
        path: ~/topgate/hogehoge

Je suis resté coincé dans config.yml

les flux de travail ne fonctionnaient pas et je n'ai pas remarqué la différence dans la description suivante et je suis resté bloqué.

Motif NG (filters est dans la même position que build.)

    jobs:
      - build:
        filters:
          tags:
            only: /.*/

Motif OK (filters est la position enfant de build.)

    jobs:
      - build:
          filters:
            tags:
              only: /.*/

Le travail ne répond pas avec git tag

Dans 1.0, la description suivante a été faite afin de déployer avec git tag.

deployment:
  prod:
    tag: /release-.*/
#・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・
  dev:
    branch: develop

Dans 2.0, le travail ne commence pas par git tag, mais le travail commence à utiliser workflows.

Git Tag Job Execution https://circleci.com/docs/2.0/workflows/#git-tag-job-execution

Les jobs avec «2.0» répondent par défaut aux changements de branche, mais pas au balisage. Vous devez donc créer un filtre pour les balises à l'aide de filters afin que le travail commence par le marquage.

En fait, il a été décrit comme suit.

version: 2
jobs:
  build:
    #・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・
    - deploy:
        name: deploy to prod
        command: |
            if [[ "${CIRCLE_TAG}" =~ ^release-.* ]]; then
                #・ ・ ・ ・ ・ ・ ・ ・ ・ Commande de déploiement (omise) ・ ・ ・ ・ ・ ・ ・ ・
            fi
    - deploy:
        name: deploy to dev
        command: |
            if [ "${CIRCLE_BRANCH}" == "develop" ]; then
                #・ ・ ・ ・ ・ ・ ・ ・ ・ Commande de déploiement (omise) ・ ・ ・ ・ ・ ・ ・ ・
            fi
#・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・
workflows:
  version: 2
  build-deploy:
    jobs:
      - build:
          filters:
            tags:
              only: /.*/