Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

BogdanGiroe's avatar

Laravel microservices - include/exclude piplines

Here is the structure:

MainFolder:

.drone.yml

  • Microservices
    • Microservice-1
    • Microservice-2
    • Microservice-3

If I change the Microservice-1(and make a commit) I want to trigger the build pipline for microservice 1

If I chnage the Microservice-2(and make a commit) I want to trigger the build pipline for microservice 2

If I change the Microservice-2(and make a commit) I DON'T want to trigger the build pipine for microservice 1

I tryed this but it did not work

  event:
    exclude:
      - promote
      - rollback
  paths:
    include:
      - ./Microservices/Microservice-1/**  # Trigger the above pipline only if the change was from this microservice
0 likes
7 replies
martinbean's avatar

@bogdangiroe So set up separate pipelines for each of your microservices?

Isn’t that the entire point of microservices? That they’re completely independent of one another?

BogdanGiroe's avatar

@martinbean So I should create .drone.yml for each microservice? If I do this it did not trigger any pipline. I believe I should have a .drone.yml in the root of the project directory

BogdanGiroe's avatar

@martinbean A drone.yml file is a configuration file used in Drone CI (Continuous Integration), an open-source platform for automating the software development pipeline. This file defines the build and deployment pipeline steps for a project, specifying how and when to build, test, and deploy the code. Here is an example

---
kind: pipeline
type: docker
name: build-api-gateway service

steps:
  - name: install npm dependencies
    image: node:18
    commands:
      - cd Microservices/api-gateway/src-apiGateway
      - npm ci
  - name: npm dependencies audit
    image: node:18
    failure: ignore
    commands:
      - cd Microservices/api-gateway/src-apiGateway
      - npm audit
    depends_on:
      - install npm dependencies
  - name: install composer dependencies
    image: docker-hub.gsd.com.ro/drivein-group-api-gateway/docker:main
    commands:
      - cd Microservices/api-gateway/src-apiGateway
      - composer install
  - name: run static analyzer
    image: docker-hub.gsd.com.ro/drivein-group-api-gateway/docker:main
    depends_on:
      - install composer dependencies
    commands:
      - cd Microservices/api-gateway/src-apiGateway
      - composer run --timeout=0 phpstan -- --no-progress
  - name: run PHP CS Fixer
    image: docker-hub.gsd.com.ro/drivein-group-api-gateway/docker:main
    depends_on:
      - install composer dependencies
    commands:
      - cd Microservices/api-gateway/src-apiGateway
      - composer run --timeout=0 php-cs-fixer
  - name: run PHP rector
    image: docker-hub.gsd.com.ro/drivein-group-api-gateway/docker:main
    depends_on:
      - install composer dependencies
    commands:
      - cd Microservices/api-gateway/src-apiGateway
      - composer run --timeout=0 rector
  - name: run prettier
    image: node:18
    depends_on:
      - install npm dependencies
      - install composer dependencies
    commands:
      - cd Microservices/api-gateway/src-apiGateway
      - npm run prettier
  - name: build UI
    image: node:18
    depends_on:
      - run prettier
    commands:
      - cd Microservices/api-gateway/src-apiGateway
      - npm run build

image_pull_secrets:
  - docker_nexus

trigger:
  event:
    exclude:
      - promote
      - rollback
  paths:
    include:
      - ./Microservices/api-gateway/**  # Include all files and subdirectories
martinbean's avatar

@BogdanGiroe Right. So again, the entire point of microservices is that they’re completely separate so that they can be developed in whatever language, by whatever team, and deployed and scaled as they‘re needed.

If all of your “microservices” are in a single repository, ran through a single CI pipeline, and deployed together then it sounds like you don’t have microservices at all, and just randomly broke a monolith into separate “apps” in different folders and decided to call them “microservices” even though you’ve got absolutely none of the benefits of advantages actual microservices would give you.

1 like
BogdanGiroe's avatar

@martinbean This means I should have each microservice in a separate repository right? With pipline for each repository

JussiMannisto's avatar

@BogdanGiroe Like @martinbean said, you don't have any microservices right now. You have one monolithic app.

The more pertinent question is: why are you talking about microservices to begin with? What problem are you trying to solve?

1 like

Please or to participate in this conversation.