Skip to main content

PHP

In the PHP preparation stage, it is essential to manage dependencies efficiently before moving on to the later phases of the CI/CD cycle. Two key preparations will be made here:

Installation of all dependencies (development and production): At this stage, a preparation will be executed to install all the dependencies required for the project. This will include both production dependencies, which are essential for the operation of the application in a production environment, and development dependencies, which are useful during the development and testing process. The installation of all dependencies ensures that the project is fully functional in this construction environment.

Installation of production dependencies for the creation of optimized images: In order to optimize the construction of container images and to reduce the size of the container images, additional preparation will be carried out, which will focus exclusively on installing the production dependencies. These production dependencies are the ones that will actually run in a production environment, and separating them into a separate preparation allows you to create lighter and more efficient container images, eliminating the need to include unnecessary development dependencies in production images.

Integration with Gitlab​

As we have just mentioned, we are going to configure two jobs. The first one will be in the pipeline preparation stage and we will call it "composer". The second one will be in the "build" stage and will be called "composer_prod".

All dependencies (composer)​

For the preparation of the necessary dependencies in the testing stage, we will create a stage that we will share with the rest of the stages through the GitLab Runner cache, which will significantly improve the efficiency of our pipeline. In this step, we will not generate artifacts since we will not require their discharge later. Optimizing the preparation stage is essential to ensure that all subsequent tests run efficiently and without missing dependency issues. By using the GitLab Runner cache, we avoid the need to re-download the same dependencies at each stage of the pipeline, which significantly speeds up the process of building and testing our application.

This stage named .dependencies_cache is responsible for managing the dependencies cache for the current project in GitLab CI/CD.

.gitlab-ci.yml
.dependencies_cache:
  cache:
    key: $CI_PROJECT_NAME-osdo
    paths:
      - vendor/

The dot in front of a stage name in GitLab CI/CD, such as .dependencies_cache, is a convention used to indicate that it is a hidden or internal stage that does not run independently, but is used as part of other stages or to perform specific setup, preparation or cleanup tasks in the pipeline, but is not started by itself.

In this case, the cache is being configured with the key defined as $CI_PROJECT_NAME-osdo. The key is unique for each project and is used to identify and retrieve the cache associated with that particular project.

The items being cached are specified in the list under paths. In this example, the following directories and their contents are being included:

  • vendor/: This directory is generally used in PHP projects to store third-party dependencies managed by Composer.

Once the cache is configured we can use it in our preparation stage

.gitlab-ci.yml
composer:
  image: harbor.opensecdevops.com/osdo/php-ci@sha256:c4d27b1286fb998148f7439533f83c2ca40f0358bbda6009a6a3f069e14086c0
  stage: preparation
  script:
      - composer install --prefer-dist --no-ansi --no-interaction --no-progress --no-scripts
  extends: .dependencies_cache

This stage called composer is in charge of installing PHP dependencies using Composer during the preparation stage in a GitLab CI/CD pipeline.

  • image: Specifies the Docker image to be used to run this stage. In this case, the harbor.opensecdevops.com/osdo/php-ci image is used with a specific tag (sha256:c4d27b1286fb998148f743953333f83c2ca40f0358bbda6009a6a3a0f069e14086c0) that provides a configured environment for PHP and the necessary tools.

  • stage: Defines the stage to which this stage belongs. In this case, it is in the preparation stage, which means that it will be executed before other stages in the pipeline.

  • script: Here you specify the commands to be executed in this stage. In this case, the composer install command is used to install the PHP dependencies. The different parameters following composer install have the following meanings:

    • --prefer-dist: Tells Composer to prefer to download dependencies from a compressed archive if available, rather than cloning repositories from GitHub or elsewhere.
    • --no-ansi: Prevents the output of ANSI control characters in the output, which makes the output more readable in an automation environment such as GitLab CI/CD.
    • --no-interaction: Runs Composer in non-interactive mode, which means that it will not wait for user input to confirm actions.
    • --no-progress: Disables the display of the progress of the installation of the dependencies.
    • --no-scripts: Prevents scripts defined in dependency packages from being executed. This is useful in IC/DC environments to speed up installation.

  • extends: Uses the extends directive to inherit the configuration from another stage called .dependencies_cache. This is commonly used to share configurations between different stages. In this case, .dependencies_cache configures the use of the GitLab Runner cache to store and retrieve previously installed dependencies, which significantly improves pipeline performance by avoiding repetitive download and installation of identical dependencies.

Production dependencies (composer_prod)​

.gitlab-ci.yml
composer_prod:
  image: harbor.opensecdevops.com/osdo/php-ci@sha256:c4d27b1286fb998148f7439533f83c2ca40f0358bbda6009a6a3f069e14086c0
  stage: build
  script:
      - composer install --prefer-dist --no-ansi --no-interaction --no-progress --no-scripts --no-plugins --optimize-autoloader  --no-dev 
  artifacts:
    paths:
      - vendor/

This stage called composer_prod is used to install PHP production dependencies using Composer during the build stage in a GitLab CI/CD pipeline. Let's see the differences with the previous stage:

  • stage: Defines the stage to which this stage belongs. In this case, it is in the construction stage, which means that it will be executed after the dependencies have been prepared in the previous stage and the different tests.

  • script: Here you specify the commands to be executed in this stage. The difference is that 3 more parameters have been added to optimize the dependencies in production.

    • --no-scripts: Prevents scripts defined in dependency packages from being executed.
    • --no-plugins: Disables the execution of plugins during installation.
    • --optimize-autoloader: Optimizes Composer's autoloader to improve application performance in production.

  • artifacts: Defines the artifacts to be kept after the execution of this stage. In this case, the vendor/ folder containing the PHP production dependencies is saved and passed to the job dependency that builds the image.