Verschaffen Sie sich auf dieser Seite einen Überblick http://tech.smarthr.jp/entry/2017/07/12/073000

Offizielle Dokumentation des Migrationsverfahrens https://circleci.com/docs/2.0/migrating-from-1-2/

Dokumente, die den Endpunkt für die Konfigurationsübersetzung verwenden https://circleci.com/docs/2.0/config-translation/

Verwenden Sie config-translation Endpoint, um die Konfigurationsdatei abzurufen.

Angenommen, die Build-Seite in CircleCI ist die folgende URL:

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

Im obigen Fall wäre der Konfigurationsübersetzungsendpunkt eine URL wie die folgende: Hier wird der Zweig als "Entwickeln" angegeben.

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

Die Datei wird mit dem Dateinamen "config-translation" heruntergeladen.

NG-Muster Ich habe den Benutzernamen meines GitHub-Kontos auf ": Benutzername" gesetzt und das folgende Antwortergebnis erhalten.

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

Integrieren Sie die heruntergeladene Konfigurationsdatei in das Projekt.

Beachten Sie Folgendes https://circleci.com/docs/2.0/migrating-from-1-2/

Erstellen Sie einen Ordner ".circleci" im Projektstamm, verschieben Sie die heruntergeladene Konfigurationsdatei dorthin und benennen Sie die Datei in "config.yml" um.

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

Fügen Sie die Beschreibung zu "Bereitstellung" hinzu.

Die heruntergeladene Einstellungsdatei enthält keine Beschreibung von "Bereitstellung". Sie müssen sie daher selbst schreiben.

Ein Fehler tritt im "Maven Integration-Test" auf.

#!/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

Es wird gesagt, dass pom.xml nicht existiert. pom.xml existiert in / server / pom.xml. In 1.0 war die folgende Beschreibung OK.

general:
  build_dir: server

In 2.0 wird es wie folgt konvertiert, aber da es in working_directory auscheckt, wird es in ~ / topgate / hogehoge / server / server anstelle von ~ / topgate / hogehoge / server geändert. , Pom.xml existierte und ohne pom.xml ist ein Fehler aufgetreten.

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

Ich kann mir die folgenden zwei Lösungen vorstellen. Vorschlag (1) Legen Sie bei der Ausführung des Befehls mvn das Arbeitsverzeichnis ~ / topgate / hogehoge / server / server als Option fest.

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

Vorschlag (2) Legen Sie im Checkout-Befehl path: ~ / topgate / hogehoge fest und geben Sie den Ordner der nächsthöheren Ebene an.

    - checkout:
        path: ~/topgate/hogehoge

Ich steckte in config.yml fest

Workflows funktionierten nicht und ich bemerkte den Unterschied in der folgenden Beschreibung nicht und blieb stecken.

NG-Muster (Filter befindet sich an derselben Position wie Build.)

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

OK-Muster (Filter ist die untergeordnete Position von Build.)

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

Job antwortet nicht mit "git tag"

In 1.0 wurde die folgende Beschreibung gemacht, um mit git tag bereitzustellen.

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

In 2.0 beginnt der Job nicht mit git tag, sondern der Job beginnt mit workflows.

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

Jobs mit 2.0 reagieren standardmäßig auf Zweigänderungen, jedoch nicht auf Tagging. Sie müssen also einen Filter für das Tag mithilfe von "Filtern" erstellen, damit der Job mit dem Tagging beginnt.

Eigentlich wurde es wie folgt beschrieben.

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