[JAVA] Projet CI pour Maven sur AppVeyor

C'est un mémorandum parce que j'ai étudié le projet Maven + Java créé dans l'article suivant avec l'intention de le tourner avec CI. https://qiita.com/kasa_le/items/db0d84e3e868ff14bc2b

AppVeyor

Vous pouvez vous inscrire ici. https://www.appveyor.com/

Fonctionnalité

Fondamentalement, il semble que l'objectif principal soit de s'appuyer sur Windows ou Visual Studio.

Vous pouvez également vous connecter à Git autre que Github, GitLab et Bitbucket. (* Cependant, il existe certaines restrictions. Voir ci-dessous) De plus, je devais me connecter à SSH avec Git, mais AppVeyor le prend également en charge.

Il prend également en charge la mise en cache.

Il y a aussi macOS (Catalina, Majave) et Ubuntu en tant qu'images OS, mais j'ai eu beaucoup de problèmes car il n'y avait pas de modèle pour la version Maven ou quelque chose comme ça.

Frais

Gratuit pour l'open source. En dehors de cela, il s'agit essentiellement de frais mensuels. Si le projet semble être opérationnel, mais qu'il a expiré, cela peut être une bonne chose car il est facile d'estimer le coût. Il n'y a pas de mention particulière du nombre de membres de l'équipe, donc je pense qu'il n'y a pas de limite. https://www.appveyor.com/docs/team-setup/

Performance

Sakura Editor est célèbre en tant qu'éditeur de texte facile à utiliser sous Windows, mais il semble qu'AppVeyor soit utilisé. (Il semble être utilisé avec Azure Pipelines)

Réglage

Fondamentalement, les travaux CI sont définis en plaçant un fichier appelé ʻappveyor.yml` directement sous la racine du projet.

1. Modifier les paramètres de construction MS

La première chose à faire est que la génération est une version MS (pour Visual Studio), vous devez donc la désarmer de votre navigateur.

--Ouvrez la page du projet et sélectionnez [Construire] dans l'onglet [Paramètres].

--Sélectionnez [Script] à côté de [MS Build]

--Cliquez sur [Enregistrer]

Ceci termine la préparation.

2. Créez ʻappveyor.yml`

Pour le moment, voici ʻappveyor.yml`, qui a finalement été construit et testé avec succès.

appveyor.yml

# Branches
branches:
  only:
  - feature/for_ci_test
image: ubuntu

install: 
- sh: sudo add-apt-repository --yes ppa:rpardini/adoptopenjdk
- sh: sudo apt-get update
- sh: sudo apt-get install -y adoptopenjdk-11-jdk-hotspot-installer
- sh: sudo apt install adoptopenjdk-11-jdk-hotspot-set-default
#/usr/lib/jvm/adoptopenjdk-11-jdk-hotspot
- sh: export JAVA_HOME=/usr/lib/jvm/adoptopenjdk-11-jdk-hotspot
- sh: echo $JAVA_HOME
- sh: export PATH=${PATH}

before_build:
- mvn -v

build_script:
- mvn clean package -DskipTests

test_script:
- mvn install verify

on_finish:
  - sh: |
      find "$APPVEYOR_BUILD_FOLDER" -type f -name 'TEST*.xml' -print0 | xargs -0 -I '{}' curl -F 'file=@{}' "https://ci.appveyor.com/api/testresults/junit/$APPVEYOR_JOB_ID"
      
artifacts:
  - path: "**/target/*.?ar"

version: "1.1.{build}"

Le contenu est le suivant,

• section succursales --Exécuter uniquement sur la branche feature / for_ci_test
• OS
  • ubuntu
• Section ʻInstall--Installez openjdk-11 et définissez le chemin --JDK 11 peut également être défini commestack: jdk 11`, mais il a dû être installé séparément car la version du JDK à bord est ancienne et le bogue n'a pas été résolu. «La raison pour laquelle j'ai défini le chemin par la force est que la méthode de basculement entre les autres versions n'a pas fonctionné.
• Sectionbefore_build --Vérifier la version de Maven
• Sectionbuild_script --maven build (ignorer le test JUnit)
• sectiontest_script --mvn commande (avec test)
• Section ʻOn_finish`
• Télécharger le rapport de test JUnit vers la page de rapport
• Section ʻArtifacts--Enregistrer* .jar et * .war` comme artefacts
• sectionversion
• Paramètres de version de construction

Si vous validez et poussez ceci directement sous la racine du projet, CI commencera à s'exécuter.

Puisqu'il peut être mis en cache, il peut être bon de cibler les dossiers Java. Dans ce cas, vous devez réécrire la partie commande sh pour décider d'installer jdk en fonction de la présence ou de l'absence du cache.

Précautions lors de la connexion à Git autre que le service de référentiel Git

Dans le référentiel Github, si je mets le ʻappveyor.yml ci-dessus, il se construit en l'utilisant, mais lors de la connexion à Git autre que les services de référentiel ** tels que Github, GitLab, Bitbucket ** (par exemple, en interne) (Git server etc. mis en place dans) est placé dans le projet ʻappveyor.yml Je n'ai pas du tout l'air de me voir.

Pour le moment, des paramètres similaires peuvent être définis à partir du navigateur, mais cela a demandé beaucoup de travail car je devais le définir ici et là sur les pages, et il était difficile d'atteindre l'endroit qui démangeait, alors je vais envisager de l'utiliser. Si vous devez faire attention.

Impressions

A l'origine c'était pour construire avec Visual Studio, donc c'était aussi pour des projets comme C #, et j'avais l'impression qu'à part ça, il n'y avait pas beaucoup de focus. J'ai honnêtement pensé qu'il serait préférable d'envisager un service CI riche de ces modèles.

De plus, mon exemple de projet (Jersey Sample) a réussi la génération et le test, mais un autre projet exécuté dans le même environnement n'a pas pu être transmis dans l'état suivant.