web-dev-qa-db-fra.com

Déployer des pages GitLab pour différentes branches

Je déploie mon React app en utilisant GitLab Pages, et cela fonctionne bien.

Voici mon gitlab-ci.yml:

# Using the node Alpine image to build the React app
image: node:Alpine

# Announce the URL as per CRA docs
# https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/README.md#advanced-configuration
variables:
  PUBLIC_URL: /
# Cache node modules - speeds up future builds
cache:
  paths:
  - client/node_modules

# Name the stages involved in the pipeline
stages:
- deploy

# Job name for gitlab to recognise this results in assets for Gitlab Pages
# https://docs.gitlab.com/ee/user/project/pages/introduction.html#gitlab-pages-requirements
pages:
  stage: deploy
  script:
    - cd client
    - npm install # Install all dependencies
    - npm run build --prod # Build for prod
    - cp public/index.html public/404.html # Not necessary, but helps with https://medium.com/@pshrmn/demystifying-single-page-applications-3068d0555d46
    - mv public _public # CRA and gitlab pages both use the public folder. Only do this in a build pipeline.
    - mv build ../public # Move build files to public dir for Gitlab Pages
  artifacts:
    paths:
    - public # The built files for Gitlab Pages to serve
  only:
    - master # Only run on master branch

Maintenant, je viens de créer une version de développement, basée sur ma branche develop

Je voudrais avoir 2 versions de mon application React avec 2 URL différentes. Comment faire?

Par exemple en ce moment, j'ai:

my-react-app.com lié à la branche master

Comment devrais-je avoir

dev.my-react-app.com ou même my-react-app.gitlab.io lié à la branche develop?

gitgitlabgitlab-pages
9
Juliatzin del Toro

Il est possible de conserver plusieurs pages publiées pour différents pipelines/branches.

Pour ce faire, vous devez copier le contenu de vos pages (essentiellement un rapport de test ou tout ce qui doit être publié) dans un répertoire unique spécifique dans un dossier public. Par exemple, le nom du répertoire peut être l'id du pipeline (CI_PIPELINE_ID). Ainsi, le chemin vers les sources des pages serait comme public/$ CI_PIPELINE_ID/.

Ensuite, l'ensemble du dossier public doit être défini comme des artefacts avec un nom unique spécifique (ici encore, "$ CI_PIPELINE_ID" peut être utilisé).

Un nom unique pour les artefacts est nécessaire pour ne pas remplacer les artefacts avec la prochaine exécution du pipeline (si le nom n'est pas spécifié, le nom par défaut sera pris https: //docs.gitlab. com/ee/ci/yaml/# nom d'artefacts ).

Ensuite, vous pouvez accéder au rapport publié via le lien:

https://yourGitlab/yourNamespace/yourProjectName/{CI_PIPELINE_ID}/index.html

, cela signifie que vous pouvez accéder à tous vos rapports enregistrés en modifiant l'ID du pipeline.

Mon exemple:

stages:
  - publish

cache:
  # Required to keep artifacts from old builds, e.g. from master
  paths:
    - public

pages:
  stage: publish
  script:
    - mkdir -p public
    - mkdir -p public/$CI_PIPELINE_ID/
    - cp target/site/allure-maven-plugin/* public/$CI_PIPELINE_ID/ -R
  artifacts:
    name: "$CI_PIPELINE_ID"
    paths:
      - public
    expire_in: 5 days
  when: always
9
Vladyslav Pyrozhok

J'ai réussi à utiliser les artefacts navigables à cet effet. Dans votre exemple, vous devez créer un travail pour votre branche de développement et définir le PUBLIC_URL vers le chemin sur gitlab.io où les artefacts du travail sont publiés:

develop:
    artifacts:
        paths:
          - public

    environment:
        name: Develop
        url: "https://$CI_PROJECT_NAMESPACE.gitlab.io/-/$CI_PROJECT_NAME/-/jobs/$CI_JOB_ID/artifacts/public/index.html"

    script: |
        # whatever

    stage: deploy

    variables:
        PUBLIC_URL: "/-/$CI_PROJECT_NAME/-/jobs/$CI_JOB_ID/artifacts/public"

La définition de environment comme indiqué produit un lien "Review app" dans les demandes de fusion pertinentes, vous permettant d'accéder aux artefacts en un seul clic.

Remarque : si votre référentiel est dans un sous-groupe , vous devez insérer le nom du sous-groupe à deux endroits ci-dessus entre /-/ et $CI_PROJECT_NAME pour que les URL résultantes fonctionnent.

7
joki

Chaque projet GitLab peut avoir au plus un site Pages. Je ne trouve pas de référence explicite pour cela, mais la documentation de .gitlab-ci.yml dit:

Sachez que les pages sont par défaut indépendantes des branches/balises et que leur déploiement repose uniquement sur ce que vous spécifiez dans .gitlab-ci.yml. Si vous ne limitez pas le travail pages avec le paramètre only , chaque fois qu'un nouveau commit est poussé vers une branche ou une balise, les pages seront écrasées.

Sans le paramètre only, les mises à jour de n'importe quelle branche sont publiées sur le même site Pages, écrasant tout ce qui s'y trouve. Avec le paramètre only, seule la branche fournie déclenchera une génération de Pages.

4
Chris