DEV Community: Fabio

#1 Code Challenge - Chain Of Responsibility - Python

Fabio — Thu, 19 Jan 2023 22:22:26 +0000

In my code challenges series, I am tackling code challenges and try to transform them into real world issue. With that Approach I can then build a small application to illustrate the problem better. Checkout the base Repository.

The Challenge

A support (or any other customer relationship) department usually has multiple levels of expertise or responsibility. This is the perfect place to illustrate the Chain of Responsibility pattern. I took this code challenge from a recent interview I had.

Imagine you have a sales department with three levels of employees: backoffice, account manager, and director. Whenever a case is automatically created, it must be first allocated to a backoffice employee who is free. If the backoffice employee can't handle the case, he or she must escalate the case to an account manager. If the manager is not free or not able to handle it, then the case should be escalated to a director.

Theory of Chain of Responsibility

I think there are many better ways to explain the Chain of Responsibility pattern than I can do. However, I will give a very brief overview of wht it actually is.

Definition: (source)

The Chain of Responsibility pattern is a behavioral design pattern that allows you to pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain.

In our particular case the chain of responsibility is the following:

Backoffice
Account Manager
Director

Every employee can decide for them selfs if they can handle the case or not. If they can't handle it, they pass it to the next employee in the chain. If they can handle it, they do so and the chain is broken.

End Product

I created a minimal Flask app which accepts cases and then on a second thread I have running a self written queue system. So nothing production ready, but it illustrates the problem. I will try to walk you through the app in the following sections. The App only has two views. You can find the code on Github.

Code

I think it is always helpful to understand the entry point of an application, which is inside app.py. There the Flask app is created, routes are registered and the second thread is started on which the TicketSystem Class is running.

Here is the app schematically represented:

Core Logic

The heart of the application is the TicketSystem Class. This class is running on a second thread and is responsible for handling the tickets. In combination with the Employee classes the Chain of Responsibility pattern illustrated.

Let us First look at the TicketSystem:

class TicketSystem:
    # Constructor
    def __init__(self, back_office_employees: Set[Employee], account_managers: Set[Employee], directors: Set[Employee]):
        self.tickets = []
        self.history = []
        self.back_office_employees = back_office_employees
        self.account_managers = account_managers
        self.directors = directors
        print(self.back_office_employees)

    # Core Logic
    def work(self):
        """
        This method is running on a second thread and is responsible for handling the tickets.
        """
        try:
            while True:
                if len(self.tickets) > 0:
                    ticket = self.tickets.pop(0)
                    self.assign_case(ticket)
        except KeyboardInterrupt:
            print("Keyboard interrupt")
            exit(0)

    def dispatch_case(self, ticket: Ticket):
        """
        This method is called by the Flask app and adds the ticket to the queue.
        """
        self.tickets.append(ticket)
        self.history.append(ticket)

    def assign_case(self, ticket: Ticket):
        """
        This method is responsible for assigning the ticket to the right employee. Called by the work method on the second thread.
        """
        employee = self.get_employee(ticket)
        if employee is None:
            return
        employee.assign_case(ticket, callback=self.handle_employee_response)

    def handle_employee_response(self, status: bool, employee, ticket: Ticket):
        """
        Employee callback to inform the TicketSystem about the status of the ticket and whether it needs to be put back into the queue.
        """
        print("Ticket", ticket.title, "was handled by", employee.name, "with status", status)
        if not status:
            self.tickets.append(ticket)

    def get_employee(self, ticket: Ticket):
        if ticket.difficulty == 1:
            return self.get_free_back_office_employee()
        elif ticket.difficulty in (1, 2):
            return self.get_free_account_manager_or_director()
        elif ticket.difficulty in (1, 2, 3):
            return self.get_free_director()

    # Start of Helpers
    def get_free_back_office_employee(self):
        for employee in self.back_office_employees:
            if employee.is_free:
                return employee
        return None

    def get_free_account_manager_or_director(self):
        for employee in self.account_managers:
            if employee.is_free:
                return employee
        for employee in self.directors:
            if employee.is_free:
                return employee
        return None

    def get_free_director(self):
        for employee in self.directors:
            if employee.is_free:
                return employee
        return None

So what is happening here? The Flask End point calls the dispatch_case method which adds the ticket to the queue (self.tickets). The work method is running on a second thread and is responsible for handling the tickets. It calls the assign_case method which uses the helper get_employee. This method is responsible for finding the right employee for the ticket. So here we can see our chain. If the difficulty of the ticket is 1, we are looking for a free back office employee. If the difficulty is 2 or 3, we are looking for a free account manager or director. If the difficulty is 3, we are looking for a free director.

The difficulty is set directly on the Ticket class and can be raised by the employee. Below you can see the call to the assign_case method of the employee. So we give the employee the ticket and a callback function which.

    def assign_case(self, ticket: Ticket, callback):
        """
        This method is called by the TicketSystem and set the employee instance up to be blocked and starts the work on the ticket.
        """
        self.is_free = False
        result = self.handle_ticket(ticket)
        callback(result, self, ticket)

    def handle_ticket(self, ticket: Ticket):
        """
        Here we can see the simulated work of an employee on a ticket.
        (In a real system this would be an employee working on a ticket and either closing it or escalating it)
        """
        ticket.start(self)
        if not self.can_handle_task(ticket.difficulty):
            self.is_free = True
            return False
        sleep(self.calculate_sleep_time(ticket))
        ## I will later speak how I simulated the escalation
        if self.can_handle_task(ticket.target_difficulty):
            ticket.close(self)
            self.is_free = True
            return True
        else:
            ticket.escalate()
            self.is_free = True
            return False

As we can see the employee either raises the difficulty of the ticket or closes it. If the ticket was closed we return True and the ticket stays removed from queue. If the ticket was escalated we return False and the ticket is put back into the queue, inside the callback function TicketSystem.handle_employee_response.

To simulate the required level of expertise on a ticket I simply have two difficulties set on a ticket. The target_difficulty is the required level of expertise and the difficulty is the current level of expertise. If the employee escalates the ticket, then the difficulty is raised by one. This will happening till the difficulty is equal to the target_difficulty and an employee can handle the ticket.

Ticket class:

class Ticket:
    def __init__(self, title: str, description: str, target_difficulty: int = 1):
        if target_difficulty < 1 or target_difficulty > 3:
            raise ValueError('Difficulty must be between 1 and 3')
        self.id = uuid4()
        self.title = title
        self.description = description
        self.difficulty = 1 # 1 = easy, 2 = medium, 3 = hard
        self.target_difficulty = target_difficulty # back office employee difficulty target
        self.status = TicketStatus.OPEN
        self.history = []
        self.current_employee = None
        self.start_time = None
        self.end_time = None

I always love to engage with readers 🚀

Do you need help, with anything written above?
Do you think I made a good example? 😄
Do you think I can improve?
Did you like the article? 🔥

5 Things that make you a good developer

Fabio — Mon, 03 Oct 2022 10:35:51 +0000

In all honesty, I find it very pretentious of myself that I write this article. However, just today I read an article on medium which had the same topic, and it was just so wrong in my opinion. What the other article confused were different concepts, and it valued experience more over problem-solving skills and motivation. So I thought I will drop my opinion here. In this article I will not tell you that you need to love what you do or be motivated, I take that as given if you opened this article!

Why does this even matter? 😎😉😋

Programmers are often proud of their work, because very often we solve a problem for the first time in our life. This makes us proud of ourselves and of the work we have delivered. Due to self reflection, we then usually want to compare ourselves to others to get a sense for our "standing". Many people would argue that being proud is imporatant to be a good programmer, my personal opinion is that you need to be proud of your work to even have the motivation to be good at your work (not only for programming).

But being proud of our code can actually be also in our way!

1. Not open for criticism on our new solution

If we have solved a very hard problem for the first time, guess what chances are that there are much better solutions out there. However, we have put our time and effort in writing this (cough peace of garbage) implementation. So if now a colleague walks up to us after we have submitted our PR and starts to directly give "good advice", it is important to take a deep breath 👼 stay open to their ideas. Even if it is your first year junior! Being open to the opinion of others lets you improve drastically and learn a lot. If you have valid arguments against their ideas, it is a moment where you can teach your colleagues. So either way, a person will probably learn something. However, if you are just going to ignore their comments, then you will lose the opportunity to improve or teach. So be open on your PR and your code will become much better. None is a god programmer and if you think you are you might wanna change your attitude.

To improve this ability it is often simple enough to tell yourself "to be open" before you go through PR comments.

2. Being able to read others people code 🌜🌛

I often see people implement a feature twice or even more often, because they are not able to properly read others people code and use their implementation. So, it comes easier to them to implement the feature from scratch or pull in a new library instead of working out how the code base handled functionality like this before. Or sometimes the current feature is not 100% what they need, so instead of refactoring the current solution to make it more generic and reusable for even future features, they fall back into the bad habit of pulling everything off by themselves. Many of us have started to code alone, without any team, so when people then get started they actually never have read complex implementations from other people.

I mean it is fair enough, often a project has a certain style (or worse no style 😷 😵) and every developer has a certain style as well. Hence, big companies have often such rigid code guidelines.

To improve this simply take more often the harder path and read the other's code properly on a feature request and try to reuse what is there and if required properly refactor it. Often you can also simply see who has committed this piece of code and maybe asked for some initial guidance. I promise if you are going to do this, you will see drastic improvements in your productivity and quality.

3. Grasping the bigger picture 🌌🌌🌌

Nowadays, applications are growing more complex, so it is often hard to understand every detail of an app. However, I think it is crucial to understand the bigger picture. To understand the bigger picture I think it is important that you categorize the "products" or services your company is offering into three sections.

Services and the level of understanding a good programmer has to them.

Directly work with this service 💻
Require Data from this service 📞
One or more Service hops away from my working area 📡

(1) A service on which you are directly working on should become very well known with time. So even if the app is so big that you cannot know all parts of it in detail, at least you should be able to tell where the start of an API is and what the expected outputs are. This helps you to understand the application flow and something like your request or event life cycles. Once you have this internalized, it will become much easier to debug the overall application. Because you know where to start and how to climb down the logic.

(2) If you are just requiring data of this service, you should grasp the overall workflow, like how is authentication set up, so I can use the service or how is the overall API Schema to quickly evaluate newly added or reworked APIs. Often APIs are being added or reworked and a particular someone has forgotten to update the god damn documentation! Again!!! 😡😡😡 But if you know how to deal with the API (and given it is a half way decent API 😅) you are likely to figure out what has changed.

(3) If you work at such a big company that you have a microservice structure like Netflix, then it becomes very hard to exactly know how every API is working. But this brings me back, to knowing the overall picture. What you can easily know is what does this service (inputs and outputs). Once you know what all services do, you can often draw a picture in your mind (or literally draw it if it helps you) to understand what the overall flow is. This helps you to understand if for instance a level 2 service is breaking because it requires data from a level 3 service in the wrong way. Then you can much more effectively create an issue report. Better issue reports are als being valued by your colleagues (FYI 😉).

4. Use the provided tooling 😩😩😩

I think it is crucial to understand what tooling your company uses and at least how it can benefit you as a developer. I see more than often, developers ignoring tools that their company is providing to them. Tools which have been build or are being paid much money for to improve the developer experience. Why do they ignore it? I think often it is that they are not interested in learning this, because it works like they are doing it currently. Often they cannot see the benefit it will bring them, and only see the effort they need to invest in order to learn the tool. And in all honesty, who can blame them? We developers are having a lot on our mind and are constantly learning. But to be more productive it is important to use the tooling which is provided and if it does not suit you should ask to improve the tooling. A great developer will have their tools ready to use. And if you can share these with others, even better.

Let me give an example here, maybe your company use Axiom or Elastic for logging http requests. Then it should become second nature to utilize this for your debugging process. Or you have well-made docker container which ships with a debugger? Then stop using prints and use the debugger. Ah and did I mention that a debugger is awesome. I wrote btw an article on how to set up Laravel in docker with a debugger you might want to check that out. 😄

Even more importantly start using a debugger!!! 😒😒😒

It is unimaginable, how often I have solved an issue within a few minutes, where my colleagues have struggled for a long time, simple due to the fact that they used prints instead of a debugger.

Debugger = King ⚡⚡⚡

5. Putting in the effort to learn the frameworks your company is using

I think this is something which is often true for smaller companies or some freelancer, which often work on a tighter belt. Frameworks are there to help you, so take that help and stop to implement your own shitty solution. If a part of it is not perfect suited for your needs, you might want to simply extend the framework. But in order to do that, you need to understand the framework.
I know I know, Frameworks have opinions, and you may or may not agree with them. However, if you are using a framework, please try to stick to the framework's opinion as closely as possible. Probably smart people have thought something of these opinions 😛.

If you are not feeling very strong in a particular framework or library, but you will need to use it, please spend the time to learn at least the basics. I think if you are going to be open to your lead or boss that you will need 2 to 4 hours learning a framework which you should extensively use, then almost none will decline your request. If they will you might wanna look for a better learning enviornment. 🔎🔎🔎

LET ME KNOW 🚀🚀🚀

What is your top 5?
Did you like the article? 🔥🔥🔥
I appreciate any feedback

Cypress and Page Object Pattern - Good practice for EndToEnd testing

Fabio — Sat, 30 Jul 2022 08:52:00 +0000

In this article, I will show you how you can adapt the Page Object Pattern in conjunction with a naming convention to save you a ton of time while writing your tests. First we start off with a naming convention and then how we can use Page Object Pattern to our advantage.

Have a look at the end result of the tests.

Be consistent with the naming of your Attribute

This is pretty much a no-brainer, but becomes very important the bigger the project is. If you utilize your naming properly, you will be able to abstract your tests in a very neat way. For instance, you can build selectors based on your component names and actions. What I often do is:

<button class="registration-button"
data-test="registration-page__button-start">Register</button>

<button class="open-settings"
data-test="settings-page__button-open">Settings</button>

so I follow these conventions all the time, depending on the project:

// it is just important that you are consistent with it and have a system in place
<page-name>__<element-type>-<semantic-action>
or even
<page-name>-<component-name>__<element-type>-<semantic-action>
or just
<component-name>__<element-type>-<semantic-action>

This helps me to unify selectors and I do not even need to look 👀 at my markup anymore. The first example button is starting the registration process, hence start, the second button is opening a widget/components, hence open. I would recommend that you take the time and define your semantic action and properly communicate them with your team. Good testing starts with a solid naming convention.

If you do this you can save so much time, have a look at the next section where I show how you can utilize this even more.

Split up the test into a reusable Structure

So, with everything in coding once you start to copy your code around you might better off writing a function (I mean fair enough if you just copy one logic from one place to another, and you are sure you will not need it more often than that.) Splitting up your code into semantic logical chunks makes a lot of sense, for maintainability. And if you are going to spend your time writing end-to-end tests, you will spend 10x more on it if you have a huge project, which does not share any logic.

There are two main patterns I have come across and which make more or less sense for certain apps. One is the Page Object Pattern and the other is the Function Object Pattern (at least I call it like this 😅). However, in this article I just show the Page Object Pattern, let me know if you are interested in a more function based approach. 😎

Page Object Pattern

Okay, so the Page Object Pattern is a way of semantically grouping page elements into classes. It is often frowned up on, because it can add a layer of complexity to a smaller project. However, classes do have their space, espacially if the project gets big. Let me show you how I utilize classes in a way to save you a ton of time and improve readability.

Let's say we have two components, which represent both a form, both can be opened and both have submitted buttons and error messages. So, without having seen the component, we already can picture what the test will need to do:

Open the Component (if it is closed) or simply scroll to it
fill out the required input with false data
submit and evaluate if error message(s) are displayed
fill out with correct data
submit and evaluate the success message(s)

In fact, pretty much all form components do this! So we can abstract all of it into a base class like this:

/**
 * The Widget Test Interaction Page Object - abstract class!!
 */
class FormPageObject {
  defaultOpenSelector = '';
  defaultSubmitUrl = '';
  defaultSubmitButtonSelector = '';
  defaultInterceptName = '';
  defaultSelectorForStringInputChange = '';
  defaultCloseSelector = '';
  defaultMessageSelector = '';

  /**
   * Opens the widget
   */
  open(
    selector = this.defaultOpenSelector,
    options = {},
    inputSelector = ''
  ) {
    return cy
      .$(selector, options, inputSelector)
      .click({
        force: true,
      })
      .scrollIntoView({ offset: { top: -100, left: 0 } });
  }


  /**
   * Close the  widget
   */
  close(
    selector = this.defaultCloseSelector,
    options = {},
    inputSelector = ''
  ) {
    return cy.$(selector, options, inputSelector).click({
      force: true,
    });
  }


  /**
   * The intercept will register with the default name and url and will look for the next request
   * hence you can wait for it. By default it is expecting that the response will work.
   * You can also force a success true
   */
  interceptSubmit(
    forceSuccess = false,
    forceFailure = false,
    shouldSucceed = false,
    inputUrl = '',
    interceptName = this.defaultInterceptName,
  ) {
    const url = inputUrl ?? this.defaultSubmitUrl;
    cy.intercept('POST', url, (req) => {
      req.continue((res) => {
        if (forceSuccess) {
          res.body.success = true;
        } else if (forceFailure) {
          res.body.success = false;
        } else if (!res.body.success && shouldSucceed) {
          expect(
            res.body.success,
            'It was not possible to change the the widget and it was expected that it would be possible'
          ).to.be.true;
        }
        return res;
      });
    }).as(interceptName);
  }


  updateStringInput(
    input = '',
    selector = this.defaultSelectorForStringInputChange
  ) {
    let newString = '';
    if (input === '') {
      return cy.stringInput(selector, input);
  }



  submit(
    selector = this.defaultSubmitButtonSelector,
    options = {},
    inputSelector = ''
  ) {
    cy.$(selector, options, inputSelector).click({
      force: true,
    });
  }



  submitValidator(req, messageSelector = this.defaultMessageSelector) {
    cy.isRequestValid(req);
    const correctClass = req.response.body.success
      ? 'alert-success'
      : 'alert-danger';
    cy.checkForClass(
      correctClass,
      messageSelector,
      `The submit request returned ${req.response.body.success}, but the message had not this class ${correctClass}`
    );
  }
}

I abstracted the code and used some of my own helper methods like cy.$ or cy.stringInput. (If you are interested how I build my helpers methods let me know in the comments) The good thing about this abstract class is that now we can use it like this:

class FormComponentA extends FormPageObject {
  defaultOpenSelector = 'form-componentA__button--open';
  defaultSubmitUrl = /regexForSubmitUrl/;
  defaultSubmitButtonSelector = 'form-componentA__button--submit';
  defaultInterceptName = 'formComponentASubmit';
  defaultSelectorForStringInputChange = 'form-componentA__input-text--type';
  defaultMessageSelector = 'form-componentA__message'
}

class FormComponentB extends FormPageObject {
  defaultOpenSelector = 'form-componentB__button--open';
  defaultSubmitUrl = /regexForSubmitUrl/;
  defaultSubmitButtonSelector = 'form-componentB__button--submit';
  defaultInterceptName = 'formComponentBSubmit';
  defaultSelectorForStringInputChange = 'form-componentB__input-text--type';
  defaultMessageSelector = 'form-componentB__message'

  // this component needs some custom interaction, e.g. a slider
  useSlider(percentage = 0, selector = 'default-selector-for-slider') {
    cy.moveSlider(selector, percentage);
  }
}

JumpToNamingConvention

Now we can write the actual test logic like this :


describe('test-for-component-A', () => {
  it('should fail and display error message', () => {
    const component = new FormComponentA();
    component.open();
   
    // e.g. update name input
    component.updateStringInput('Max');
  
    // set up the interceptor and force it to fail
    component.interceptSubmit(false, true);
  
    // hit the submit button
    component.submit();
   
    // wait for the request and evaluate the response
    cy.wait(component.defaultInterceptName).then((req) => {
      component.submitValidator(req);
    });
  });



  it('should succeed and display success message', () => {
    const component = new FormComponentA();
    component.open();

    // set up the interceptor and force it to succeed
    component.interceptSubmit(true);

    component.updateStringInput('Max');
    component.submit();
    cy.wait(component.defaultInterceptName).then((req) => {
      component.submitValidator(req);
    });
  });
});

Our tests are now very good readable 😇. I think anyone can now understand what the test is actually doing. Readable code is the first step of creating maintainable code! The cool thing is, if we want to create a test for FormComponentB we can very quickly do so!

Coming back to my earlier statement

You should use a solid naming convention for your tests attributes can really help you utilize the power of this approach.

Because you can also do stuff like this in your base class(es):

  constructor(componentName, interceptRegex) {
    this.defaultOpenSelector = `.${componentName}__button-open`;
    this.defaultSubmitUrl = interceptRegex;
    this.defaultSubmitButtonSelector = `.${componentName}__button--submit`;
    this.defaultInterceptName = `${componentName}Intercept`;
    this.defaultSelectorForStringInputChange = `.${componentName}__input-text--type`;
    this.defaultMessageSelector = `.${componentName}-message`;
  }

So now you do not even need to write a new class and can use the abstract FormClass directly. 🔥🔥🔥

const component = new FormPageObject('form-componentB');

JumpToTop.

LET ME KNOW 🚀🚀🚀

Do you need help, with anything written above?
What will be your first Image? 😄
Do you think I can improve - then let me know
Did you like the article? 🔥

Publish your own Docker Images with GitHub Actions

Fabio — Sun, 24 Jul 2022 09:41:00 +0000

In this post, I will show how easily you can set up your own docker images and then utilize GitHub Actions to deploy them to a Docker registry. This will save you set up time and make your environments more stable.

Prerequisites

Git installed and GitHub Account
Docker installed (for testing)

Get Started with Docker

Docker is a virtualization tool which allows you to require an image which comes with pre-installed configurations and software. So you can pick an operating system of your liking (NO IOS that's illegal) and then get started with installing what you need. These definitions will be written into a Dockerfile. If you don't have docker installed, head to their docs it is really simple to install.

Write your first image

Let's start with a very simple Python image. We will pull the latest distribution of Python and set the PYTHONUNBUFFERED=1 to ensure that all python output is sent to the terminal for better debugging. Paste the below lines into a Dockerfile (Yes the file has no file extension).

FROM python:latest
ENV PYTHONUNBUFFERED=1

Once you have the file, you can now run

docker build . --file Dockerfile -t ${Image_Name}

The --file can be used in case your Dockerfile has not the default name or is in another path. The -t flag is used to give the image a name. After the image build successfully on your machine, you can go ahead and try to publish it to hub.docker.com.

Next, we want to tag our image, therefore please create an account at docker hub. We will need the namespace. Before proceeding, please log in locally with docker login.

docker login --username ${USERNAME}

This will log you in and store an encrypted version of your credentials for later use locally.

To version our image we use tags, so if one image is bad due to any reason, you can always pull an earlier image. The following command will tag the image. The DOCKER_HUB_NAMESPACE is by default your username in docker hub. So for me, it would be snakepy.

docker tag "${IMAGE_NAME}" "${DOCKER_HUB_NAMESPACE}/${IMAGE_NAME}:${VERSION}"

Concrete example:

docker tag python-dev snakepy/python-dev:latest

After this, all what is left is to upload the image to docker hub, so you can use it later, therefore you need to run:

docker push "${DOCKER_HUB_NAMESPACE}/${IMAGE_NAME}:${VERSION}"

After you have uploaded your image, you can pull it from another Dockerfile and require it:

FROM ${DOCKER_HUB_NAMESPACE}/${IMAGE_NAME}:${VERSION}

WorkFlow for automation

I have created a repository where I upload my images to. The workflow is set up in a way that if I push to that repository it will automatically build all images and push them to docker hub with a new version. I also created scheduled tasks, which runs periodically to release the latest version of the image.

This is where the fun begins and once you have your automation set up you can refine it, and it will grow overtime. You can have a look at my current set up.

To automate the creation of docker images, you need to do the following steps:

create a repository for your images
set the secrets in the repository
create workflow file
profit 💰

First create the GitHub repository and then find the secrets tab, there you can add new secrets. You will need to add DOCKER_HUB_NAMESPACE, DOCKER_HUB_PASSWORD andDOCKER_HUB_USER. You can either set them as repository or workflow env. I found it easier to simply set them as repository variable.

After you have added the secrets, we can proceed to the GitHub workflow file. The file(s) need to be inside .github/workflows. In there I created two files, one for scheduled tasks and one if I push. This will help us to deal easier with the versioning of the images.

name: publish-to-docker-hub
on: [push]

env:
  DOCKER_HUB_PASSWORD: ${{ secrets.DOCKER_HUB_PASSWORD }}
  DOCKER_HUB_USER: ${{ secrets.DOCKER_HUB_USER }}
  DOCKER_HUB_NAMESPACE: ${{ secrets.DOCKER_HUB_NAMESPACE }}
  VERSION: ${{ github.sha }}

jobs:
  publish_python:
    runs-on: ubuntu-latest
    env:
      IMAGE_NAME: 'python-dev'
      LANGUAGE: 'python'
      LANGUAGE_VERSION: 3.10
    steps:
      - uses: actions/checkout@v2
      - run: echo ${DOCKER_HUB_PASSWORD} | docker login --username "${DOCKER_HUB_USER}" --password-stdin
      - run: docker build . --file ${IMAGE_NAME}/Dockerfile -t ${IMAGE_NAME}
      - run: docker tag "${IMAGE_NAME}" "${DOCKER_HUB_NAMESPACE}/${IMAGE_NAME}:${LANGUAGE}${LANGUAGE_VERSION}-${VERSION}"
      - run: docker push "${DOCKER_HUB_NAMESPACE}/${IMAGE_NAME}:${LANGUAGE}${LANGUAGE_VERSION}-${VERSION}"

First, we define the name of the workflow publish-to-docker-hub and then the action trigger. Next, we define the variables which will be pulled from the GitHub secret store. Then we define our jobs. Under Jobs, you can have multiple jobs (checkout my YAML file). We are essentially doing what I showed before. We are logging into docker hub, building the image, tagging the image and uploading the image.

Please note my repository structure! Every Dockerfile is placed like this ${IMAGE_NAME}/Dockerfile. This way I can write small documentations with it or even have config files which I can copy in during build time.

Now you should see that the action is created for every push you do. I also like an action once a month to release the latest version of the image, just to keep them fresh.

So I created a second workflow file which is essentially the same and the only difference is the trigger and the VERSION variable.

on:
  schedule:
    - cron: '0 0 1 * *'


env:
  DOCKER_HUB_PASSWORD: ${{ secrets.DOCKER_HUB_PASSWORD }}
  DOCKER_HUB_USER: ${{ secrets.DOCKER_HUB_USER }}
  DOCKER_HUB_NAMESPACE: ${{ secrets.DOCKER_HUB_NAMESPACE }}
  VERSION: latest

LET ME KNOW 🚀

Do you need help, with anything written above?
What will be your first Image? 😄
Do you think I can improve - then let me know
Did you like the article? 🔥

Check my laravel-dev image out! 🔥

5 Things I wished I had known when I started to maintain GitLab CICD

Fabio — Sat, 16 Jul 2022 11:20:00 +0000

In this post, I describe a few of the amazing concepts of GitLab CICD pipelines. They made my daily work on the CICD pipelines significantly easier.

All examples can be found here.

1. YAML Anchors

This is probably for many of you a no-brainer. When I got into CICD I was also pretty new to work with YAML files. I also did not start from scratch. I had to deal with a huge CICD file which was over 1000 lines long. I could shrink it down to a couple of hundreds line while also adding more functionality into the pipelines. I could achive this utilizing the concept of parallelization and YAML Anchors.

What are YAML Anchors?

YAML Anchors are reusable code blocks you can easily insert at a later stage. You can define entire jobs like this and based on some variables you set you can change the job. I will make an example.

Let's say we have two builds in our pipeline to perform, one for development and one for production. But for production, we need a different .env file than for development. We could just create two jobs like this below, which will result in this kind of pipeline:

stages:
  - deploy

dev_deploy:
  variables:
    - ENV_FILE: .env.test
  stage: deploy
  script:
    - source $ENV_FILE
    - echo "DEPLOY APPLICATION"

master_deploy:
  variables:
    - ENV_FILE: .env.prod
  stage: deploy
  script:
    - source $ENV_FILE
    - echo "DEPLOY APPLICATION"

These two jobs are fairly easy to read, but imagine a more complex build/bundle script and also added different rules on when to run what jobs. We can do better if we use YAML Anchors because most parts of the jobs are the same. So we can transform the above code block to the following, which will result in this kind of pipeline:

stages:
  - deploy

.deploy: &deploy
  stage: deploy
  before_script:
    - if [[ "$ENV_FILE" == '' ]] ; then echo "ENV_FILE is not set" ; exit 1 ; fi
  script:
    - source $ENV_FILE
    - echo "BUILDING APPLICATION"

dev_deploy:
  <<: *deploy
  variables:
    ENV_FILE: .env.test

staging_deploy:
  <<: *deploy

master_deploy:
  <<: *deploy
  variables:
    ENV_FILE: .env.prod

As you can see, we now share the code of across the different jobs. I also added a staging job into the mix to show that we can also prevent jobs from running if the required variables are not set for the job. When it comes to override, the stuff which comes at a later line will override the declarations of before. That is why we "spread" the deploy anchor at the top of the job.

2. Parallelization

Parallelization has similar use cases to YAML Anchors. But is somewhat different. Sometimes a job is exactly the same, but just one variable is different, and therefore it needs to be run again and again. So going back to the first example, we could also improve on it, in the following manner, which results in this kind of pipeline:

stages:
  - deploy

dev_deploy:
  stage: deploy
  parallel:
    matrix:
      - ENV:
          - test
          - prod
  script:
    - echo $ENV
    - echo .env.$ENV
    - source .env.$ENV
    - echo "DEPLOY TO $ENV"

So instead of define multiple jobs, we define one job with a parallel matrix. This will spin up the job multiple times and inject the ENV variable. This is very useful if you for instance need to build or test your app based on different environments files, because then only one CI Variable is different. The downside is that you can only spin up 50 parallel processes.

On the other hand, parallel jobs are often used to split up a big job into smaller parts and then bring everything together in the next job, or you can split your test files into parallel jobs.

3. `CI_JOB_TOKEN`

The CI_JOB_TOKEN is a pre-set variable which allows you to access or trigger other resources within a group. So if you need to trigger a multi project pipeline where for instance after the backend is deployed you want to trigger the frontend deployment the CI_JOB_TOKEN comes in very handy. But there is more! If you use the CI_JOB_TOKEN then GitLab will actually know and make a connection between these pipelines. You can jump from one project's pipeline to another project's pipeline. The call would look like this:

stages:
  - trigger_pipeline_in_other_project

trigger:
  stage: trigger_pipeline_in_other_project
  script:
    - curl --request POST --form token=${CI_JOB_TOKEN} https://gitlab.com/api/v4/projects/<PROJECT_ID>/trigger/pipeline

A resulting pipeline could look like this:

4. Clean Up Jobs

Clean up jobs are jobs which run after another job and based on the pipeline status the execution changes. So you can basically run a different job depending on the pipeline status. For instance, you can then clear the cache on failure or invalidate some CloudFront dist etc. So to utilize this concept you can do something like the following, which result in a pipeline like this:

stages:
  - build
  - deploy

build:
  stage: build
  script:
    - echo "BUILD APPLICATION"

deploy_on_failure:
  stage: deploy
  when: on_failure
  script:
    - echo "CLEAR ARTIFACTS"

deploy_on_success:
  stage: deploy
  when: on_success
  script:
    - echo "DEPLOY APPLICATION"

deploy_on_failure runs only if the build has failed, while deploy_on_success will run when the build has succeeded. This can come very handy but has limitations, that is why I really like the next concept.

5. Child Pipelines & Dynamic Child Pipelines

Child Pipelines are pipelines which are started using the combination of the trigger and include keywords. They are detached from the parent pipeline and start by default directly running when triggered. So if one stage in your CICD file is "trigger job" for a child pipeline, it will trigger the pipeline and then the next job will start immediately after. Child pipelines are defined in a second CICD file, which is included into the main file. Let me make an example, which would result in this kind of pipeline:

The main file would look like this:

stages:
  - test
  - build
  - deploy

test:
  stage: test
  trigger:
    include: test.yml

build:
  stage: build
  script:
    - echo "BUILD APPLICATION"

deploy:
  stage: deploy
  script:
    - echo "DEPLOY APPLICATION"

As you can see, the test stage includes a second YAML file, which will be triggered into the detached (child) pipeline. The file could look like this:

stages:
  - test

test:
  stage: test
  script:
    - echo "TEST APPLICATION"

So, child pipelines allow splitting your YAML files into multiple files. But they also have a constraint and can only be triggered up to two levels down. That means the first child pipeline can trigger another child pipeline, but this pipeline cannot trigger a third child pipeline. But why is this exciting, we can use other tools for splitting YAML files.

This is exciting because the triggered YAML File does not have to exist before the pipeline starts!

The above statement leads us right into Dynamic Child Pipelines. This concept is really powerful and deserves an article on its own (Let me know if I should write more about it).

Most programming languages have some sort of packages to convert a JSON like structure into a YAML file. So what you can do, you have a pre-job which will compute the YAML file for you and then passes the YAML file as an artifact to the trigger job. This way, you can decide on the fly what the child pipeline should look like.

What I am going to show is not the most elegant or dynamic way, but it is the easiest way to grasp the concept. I call this set up a pipeline switch. Let's say we have a job which computes something for us.

Example conditions:

For instance gas prices for blockchains and if the gas prices are low we want to deploy the new contracts (basically when deployment costs are low)
On every Sunday we want to deploy our frontend in a random color 😆

You get the gist, so we have some condition on which we want to alter the pipeline.

In the below example the pipeline depends on the outcome of the condition (the deployment fees):

stages:
  - build
  - check_deployment_costs
  - trigger_dynamic_child

build:
  stage: build
  script:
    - echo "BUILD APPLICATION"

check_deployment_costs:
  stage: check_deployment_costs
  script:
    - echo "RUNS SCRIPT TO CHECK DEPLOYMENT COSTS"
    - echo "query computed costs per contract are 50 Finney"
    - bash pipelineSwitch.sh 50
  artifacts:
    paths:
      - './dynamicChildPipeline.yml'

trigger_dynamic_child:
  stage: trigger_dynamic_child
  trigger:
    include:
      - artifact: dynamicChildPipeline.yml
        job: check_deployment_costs

So in the step check_deployment_costs we check for the deployment costs and plug that into our bash script. The bash script is a simple check and then copies from the template folder to the location from where we will upload the artifact.

echo "input value: $1"
if [[ $1 < 51 ]]; then
    echo "should deployment"
    cp ./CICDTemplates/deployment.yml ./dynamicChildPipeline.yml
else
    echo "should wait deployment"
    cp ./CICDTemplates/sendNotification.yml ./dynamicChildPipeline.yml
fi

This solution might be as stated earlier not as elegant as other solutions but still pretty viable for a quick way. The resulting pipelines look like this, if the price is too high or if the price is okay.

LET ME KNOW 🚀

Do you need help, with anything written above?
What would be top on your list? 😄
Do you think I can improve - then let me know
Did you like the article? 🔥

My favorite Laravel development environment, with Docker, Nginx, PHP-FPM Xdebug in VSCode

Fabio — Fri, 08 Jul 2022 19:20:00 +0000

In my last post I showed how you can set up XDebug for a simple dev environment, which used php artisan serve. However, what I am showing today is actually more perfomant. Once you understand the set up, it will probably soon be your favorite Laravel dev environment as well.

The setup can be found in this repository.

Table Of Content

Why should I use the set up 😎
Requirements
Set Up Guide
- Break Down
- Dockerfiles and Xdebug Configs
- ENV Vars and docker-compose
- NGINX Configs
- Set Permissions
- Redis Lib (optional)
- First Run
VS Code Set Up
Troubleshooting 💥

Why should I use the set up

The set up is great, because you will be able to:

Use Nginx and php-fpm to process requests much faster
Use the debugger with Nginx calls
Use the debugger for the queue
Have a redis cache set up
Have a database set up
Have a php artisan serve server as fallback

Nginx with php-fpm enables parallel processing of requests, while with just the php artisan serve you will only be able to process requests in sequence.

Requirements

The only requirement is that you have a newer version of docker installed. (In older docker versions you might have to manually install docker-compose as well).

Set up Guide

Break Down

Create the Dockerfiles - I am gonna use an image that I have created for this guide (GitHub or from hub.docker)
Create the XDebug configs
Set the .env vars
Create the docker-compose
Create the Nginx config
Set the correct permissions for storage and bootstrap
(optional) Add a library for Redis

Dockerfiles and Xdebug Configs

We are going to need 3 files, 2 Dockerfiles and one docker-compose.yml file.

First the main Dockerfile for the actual app container:



FROM snakepy/laravel-dev-image:php7.4-a696761a6b37e2480ba83edc4edee9a7632f3332

WORKDIR /app

COPY .docker/xdebug.ini /etc/php/7.4/cli/conf.d/99-xdebug.ini

RUN npm install

You can see we are pulling the image which comes with all the plugins you will need. (I plan to release a PHP 8 image as well, let me know if you guys also are interested in a production image ✌️). Next we copy configs for debugging on the php artisan serve container. They can be found at (.docker/xdebug.ini):



zend_extension = xdebug

xdebug.remote_enable=on
xdebug.remote_autostart = 1
xdebug.mode=develop,gcstats,coverage,profile,debug
xdebug.idekey=docker
xdebug.start_with_request=yes
;xdebug.log=/tmp/xdebug.log
xdebug.client_port=9003
xdebug.client_host='host.docker.internal' 
xdebug.discover_client_host=0

Now we need to define a second docker file for serving the app with PHP-FPM. We need to do that because Nginx does not come with a PHP plugin. If we'd use Apache we could directly serve from Apache.



FROM php:7.4-fpm

RUN pecl install xdebug-2.9.2 \
    && docker-php-ext-enable xdebug  

RUN docker-php-ext-install mysqli pdo pdo_mysql

COPY .docker/xdebug-nginx.ini /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini

Note here we are not pulling the image I have prepared, it would be overkill, hence we are going with the default image from PHP. The Xdebug configs are being copied as well, but they are slightly different. See at (.docker/xdebug-nginx.ini):



zend_extension = xdebug

xdebug.remote_enable=on
xdebug.remote_autostart = 1
xdebug.default_enable=1

xdebug.mode=develop,gcstats,coverage,profile,debug
xdebug.idekey=docker
xdebug.start_with_request=yes
;xdebug.log=/tmp/xdebug.log
;xdebug.remote_log=/tmp/xdebug.log
xdebug.client_host='host.docker.internal' 
xdebug.discover_client_host=0
xdebug.remote_handler=dbgp

ENV Vars and docker-compose

This is by far the hardest part to get right. The docker-compose file I am going to present requires some .env vars, hence I am going to show these first.

Please set in .env following vars:



# Docker Ports
DOCKER_EXPOSED_DB_PORT=3307
DOCKER_EXPOSED_NGINX_PORT=10000
DOCKER_EXPOSED_ARTISAN_SERVE_PORT=8000

## can be retrieved with hostename -I
DOCKER_NGINX_LOCAL_IP=

## DO NOT CHANGE!If you change this, you also need to change DB_HOST and REDIS_HOST
DOCKER_APP_CONTAINER_NAME="laravel-dev-to"

DB_CONNECTION=mysql
DB_HOST=laravel-dev-to-db
DB_PORT=3306
DB_DATABASE=test
DB_USERNAME=test
DB_PASSWORD=Password123!

REDIS_HOST=laravel-dev-to-cache
REDIS_PASSWORD=REDIS_PASSWORD
REDIS_PORT=6379

Note that DOCKER_APP_CONTAINER_NAME is used as a prefix in the docker-compose hence the naming convention to DB_HOST and REDIS_HOST must be maintained.

Let's look at the docker-compose.yml:



version: '3.8'
services:
    app:
        container_name: ${DOCKER_APP_CONTAINER_NAME}
        extra_hosts:
            - "host.docker.internal:host-gateway"
        build: 
            context: .
            dockerfile: Dockerfile
        command: php artisan serve --host=0.0.0.0
        volumes:
            - .:/app
        ports:
            - ${DOCKER_EXPOSED_ARTISAN_SERVE_PORT}:8000
        depends_on: 
            - db
            - composer
        networks:
            - proxynet
        env_file:
            - .env
    queue:
        container_name: ${DOCKER_APP_CONTAINER_NAME}-queue
        extra_hosts:
            - "host.docker.internal:host-gateway"
        volumes:
            - .:/app
        build: 
            context: .
            dockerfile: Dockerfile
        command: 'php artisan queue:work'
        environment:
            - REDIS_HOST=${REDIS_HOST}
            - REDIS_PASSWORD=${REDIS_PASSWORD}
            - REDIS_PORT=${REDIS_PORT}
        depends_on: 
            - app
            - cache
            - db   
            - composer
        networks:
            - proxynet     
    db:
        container_name: ${DOCKER_APP_CONTAINER_NAME}-db
        platform: linux/x86_64
        image: mysql:8.0
        restart: "no"
        environment: 
            MYSQL_ROOT:  root
            MYSQL_ROOT_PASSWORD: root
            MYSQL_DATABASE: ${DB_DATABASE}
            MYSQL_USER:  ${DB_USERNAME}
            MYSQL_PASSWORD:  ${DB_PASSWORD}
        ports:
            - ${DOCKER_EXPOSED_DB_PORT}:3306
        volumes:
            - db_data:/var/lib/mysql
        networks:
            - proxynet
        env_file:
            - .env
    cache:
        container_name: ${DOCKER_APP_CONTAINER_NAME}-cache
        command: redis-server --requirepass ${REDIS_PASSWORD}
        image: redis:5.0
        ports:
            - :6379
        volumes:
            - cache_data:/data
        networks:
            - proxynet
    nginx:
        image: nginx:stable-alpine
        container_name: ${DOCKER_APP_CONTAINER_NAME}-nginx
        ports:
            - ${DOCKER_EXPOSED_NGINX_PORT}:80
        volumes:
            - ./:/var/www/html
            - ./.docker/nginx/default.conf:/etc/nginx/conf.d/default.temp
        depends_on:
            - app
            - composer
            - db
            - cache
        command: /bin/sh -c "envsubst '$$DOCKER_NGINX_LOCAL_IP $$DOCKER_APP_CONTAINER_NAME' < /etc/nginx/conf.d/default.temp > /etc/nginx/conf.d/default.conf && exec nginx -g 'daemon off;'"
        env_file:
            - .env
        networks:
            - proxynet
    php-fpm:
        extra_hosts:
            - "host.docker.internal:host-gateway"
        build: 
            dockerfile: Dockerfile.PHP-FPM
        container_name: ${DOCKER_APP_CONTAINER_NAME}-php-fpm
        volumes:
            - ./.docker/xdebug-nginx.ini:/usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
            - ./:/var/www/html
        ports:
            - ":9000"
        depends_on:
            - app
            - composer
            - db
            - cache
        networks:
            - proxynet
    composer:
        build: 
            context: .
            dockerfile: Dockerfile
        container_name: ${DOCKER_APP_CONTAINER_NAME}-composer
        volumes:
            - .:/app
        command: composer install
        networks:
            - proxynet
        env_file:
            - .env

volumes:
  db_data:
    driver: "local"
  cache_data:
    driver: "local"


networks:
  proxynet:
    name: portal

Okay I am going to break down the docker-compose file so actually understand what going on there. It will build the following containers:

app the basic Laravel dev app
db a MySQL database
cache Redis cache
queue basic Laravel dev queue worker
Nginx the web server for serving to php-fpm and serving static content
php-fpm server for executing PHP code for Nginx
composer runs an install on container boot and will the exit

All these containers are being wrapped into a proxynet in case you want to use the same network in another compose file like a Vue frontend.

The variables from the .env file are being used to determine which ports are going to be exposed. In my example we are exposing php artisan serve on port 8000 and nginx on port 10000. The mysql db will be exposed on port 3307.

The last thing I want to point out about the compose file is the use of:



        extra_hosts:
            - "host.docker.internal:host-gateway"

Which basically tells docker to resolve docker-container-names to their network IP address.

In the next section we are going to take a closer look at the Nginx compose section and configs.

NGINX Configs

Let us talk about the Nginx volumes. Nginx mounts two volumes. ./:/var/www/html will be used for static file serving, like images. ./.docker/nginx/default.conf:/etc/nginx/conf.d/default.temp this volume are the actual nginx configs. If you know Nginx then you will notice that we actually put a "wrong" file name into the image default.temp. We do not mount the Nginx to the end/correct location because we require envsubst to run over it and replace two variables in the nginx.conf file.ènvsubst has the ability to run over a config file and replace only the variables with the names which were provided to it. I think this answer describes the issue very well. In the command envsubst we define the correct output path for nginx and run the Nginx deamon.

These Varibles need to be replaced and the other should not be touched:

$DOCKER_APP_CONTAINER_NAME needs to replaced so nginx can proxy all php requests to php-fpm
$DOCKER_NGINX_LOCAL_IP is required for XDebug

❗ I had a lot of difficulty getting it right, but note that you need to escape the variables for docker with two dollar signs $$. ❗

Example:



envsubst '$$DOCKER_NGINX_LOCAL_IP $$DOCKER_APP_CONTAINER_NAME'

Here is the Nginx config template you need to copy into your project, I have them at (.docker/nginx/default.conf):



server {
    listen  80;

    # this path MUST be exactly as docker-compose.fpm.volumes,
    # even if it doesn't exist in this dock.
    root /var/www/html/public;

    location / {
        try_files $uri /index.php$is_args$args;
    }

    location ~ ^/.+\.php(/|$) {
        fastcgi_pass $DOCKER_APP_CONTAINER_NAME-php-fpm:9000;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param PHP_VALUE "xdebug.remote_autostart=1
        xdebug.remote_enable=1
        xdebug.remote_host=$DOCKER_NGINX_LOCAL_IP";
    }
}

Set Permissions

Simply give the ./storage and ./bootstrap folder these permissions:



chmod -R 777 ./storage
chmod -R 777 ./bootstrap

Redis Lib (optional)

I am going to connect to redis using the libary predis. Simply add the following to your compose.json



"require": {
  ...
  "predis/predis": "^1.1",
  ...
 }

and inside config/databse.php:122 I switched to use predis.

First Run 🏁

If you have followed the previous steps now is the moment of truth: 💦 💦



docker compose run

If this is the first boot and you had no vendor folder prior to this - then wait till the compose container exits and shut the container down and rerun docker compose up.

now you should be able to hit 🚀🚀🚀:
http://localhost:8000
and
http://localhost:10000

If everything is opening up as expected then you can continue with the IDE set up for XDebug. If not then have a look a the github repo or leave me a comment and I can try to assist you. Also have a look the troubleshooting section.

Set Up VS Code

Now the set up for VS Code to actually use the debugger you need first to install the following extension.

Then copy over the launch.json file I have prepared. You will find multiple configurations in there. I will go over one so you understand whats going on.



{
  "name": "Listen for Xdebug inside docker",
  "type": "php",
  "request": "launch",
  "hostname": "0.0.0.0",
  "pathMappings": { "/app": "${workspaceRoot}/" },
  "port": 9003,
  "log": true
},

name shows up in the debugger drop down
hostname needs to be set to 0.0.0.0 so the server can find the XDebug report from localhost
pathMappings is basically a map where the folders are placed on the server => {"path_to_app_inside_docker": "${workspaceRoot}/"} the workspaceRoot is automatically set by VS Code
port the port on which XDebug will answer

If you want to debug now, you will need to run docker compose up once the containers are running you can choose from the drop down, on which requests you want to listen to. I usually just launch two debugger instances:

"Listen for Xdebug inside docker" and
"Listen for Xdebug inside docker nginx"

After the debugger is launched you should be able to hit break points, if requests are going to http://loclahost:8000 or http://localhost:10000

To test this insert this into api.php:



Route::get('/test', function () {
    return response()->json(['message' => 'Visit my portfolio site at snake-py.com'], 200);
});

The set a a break point on the return statement line and try to hit the route http://localhost:8000/api/test or http://localhost:10000/api/test

Troubleshooting

There is actually a lot of stuff which might go wrong during your first set up. I just want to mention here a few ways which helped me debug. (I also try to keep this a little updated). Feel free to open a GitHub issue or comment here for support.

Debugger does not connect?
Enable the following config, which will output a log file wiht an error you can google.



xdebug.log=/tmp/xdebug.log
xdebug.remote_log=/tmp/xdebug.log

The log file will be in the app container or the php-fpm container depending on which port your hitting. To get into the php-fpm container is no bash installed yo you need execute:



docker exec -it <php-fpm-container-name> bin/sh

Database or cache does not connect properly?
If you are sure that the containers can reach each other and that the names you have provided in the .env file are correct you can go inside the app container and run a config clear.



docker ps # to get the name of the app container
docker exec -it <container_name> bash
php artisan config:clear
php artisan cache:clear
php artisan route:clear
php artisan migrate

If one of these commands fails then you usually did not provide the correct name or port in the .env file.

Nginx is failing on boot?
Did you set the correct local ip address? Is the php-fpm container name correctly prefixed? Check with docker ps

It should look like this:

I hope I could help you with this set up let me know what you guys might think! 😄

How to debug Laravel with XDebuger in VS Code

Fabio — Tue, 05 Jul 2022 19:07:05 +0000

To be able to debug Laravel applications during development will give you a huge advantage, compared to your colleagues who are struggling their way through using echo or print_r statements. The ability to pause the execution is often crucial to understand how the code works and where the bug is.

Following steps are required:

Install XDebug
Install xdebug.php-debug for VS Code released by XDebug
create a launch.json file

The first and the second step can sometimes be relatively tricky to get right, however I am confident if you follow my instructions you will get it to work.

Install XDebug

(If you have it already installed and are just here, because the other tutorial didn't work, then I have a tip for you. Look at the configs I am providing, which will enable a different the XDebug log level. This often helps to figure out why it is not working.)

I would recommend that you head over to https://xdebug.org/docs/install and look at one of their installation guides, because it will be different for most people. If you use a Unix based system like macOS or Linux you are in luck and the installation will be easier, because you most likely can install it with PECL or Homebrew If this is not possible, simply download the zipped file and follow the instructions on their wizard page. https://xdebug.org/wizard

The same goes for Windows user. On Windows you might even first update your PHP Version since not all versions are compatible.

Take a way - the installation of XDebug will be different for most OS and PHP versions, hence it is almost impossible to give a general how to guide.

Check the main page and see if you can install it using CLI tools https://xdebug.org/docs/install
If you cannot install it with a CLI tool, head over to the wizard and past the output from php -i https://xdebug.org/wizard
Check that XDebug is properly installed - you can do that using php -i and search the output for debug. If it is installed, it should be listed under extensions. (you might need to enable it putting zend_extension = xdebug into your php.ini file)
After successful installation adjust the XDebug.config file. (The file will be named differently depending on your OS. The wizard should have told you how it was named.) If you run php -i | grep xdebug you should be able to see the file you need to configure.

To get the configs right can sometimes be quite difficult. However, the installation is actually the hardest part. Once you know where you can set the settings for XDebug it gets actually simpler.

Below, you can see possible configs for XDebug. I added comments to each line, so you actually understand what it does. Often you will see that the boolean fields are being set with either on, 1, yes - again different version need different values. However, for me, it was never an issue and could actually use these settings interchangeable.

zend_extension = xdebug

xdebug.remote_enable=on ; enables the extension
xdebug.remote_autostart = 1 ; required to be true so xdebug is started for ever php process 
xdebug.start_with_request=yes ; so it turns on for every http request

xdebug.log=/tmp/xdebug.log ; the logging - turn of once evrything works


xdebug.mode=develop,gcstats,coverage,profile,debug ; just give it the modes you need it can take all of them
xdebug.idekey=VSCODE ; can also be phpstorm

xdebug.client_port=9003 ; the port xdebug will be working on

The logging actually helped me a lot to set it up correctly, especially in docker container. I will soon release a guide for my favorite dev environment for Laravel. If you want to read more about the different modes, have a look here https://xdebug.org/docs/upgrade_guide

xdebug.log=/tmp/xdebug.log

Okay now, when you start your Laravel application with php artisan serve you should see an output where XDebug is complaining that it cannot connect. This will be solved in the next section.

Set Up VS Code

First install xdebug.php-debug for VS Code released by XDebug plugin for VS Code. Once done, find the debugger view.

Inside the Debugger view you can now create a launch.json file, this will bring down a dropdown in which you simply choose PHP. VsCode will now create a launch.json into the .vscode folder. In there you will find several configs. We are actually only interested into the first config. Here, it is crucial that the port is the same as the port in the XDebug config file.

{
    "name": "Listen for Xdebug",
    "type": "php",
    "request": "launch",
    "port": 9003
}

Once the port is the same you should be able to hit the play button in the debugger view, make sure you have selected the correct launch configs. Now you should be able to set break points.

I know I did not give you guys an exact step-by-step guide on how to install XDebug, but this is because it is so different for most people. If many of you struggle with it, I can make a video where I show how I install it. For Windows users, it might even be easier to have a look at my article where I show a docker set up.

DEV Community: Fabio

#1 Code Challenge - Chain Of Responsibility - Python

The Challenge

Theory of Chain of Responsibility

End Product

Code

Core Logic

I always love to engage with readers 🚀

5 Things that make you a good developer

Why does this even matter? 😎😉😋

1. Not open for criticism on our new solution

2. Being able to read others people code 🌜🌛

3. Grasping the bigger picture 🌌🌌🌌

4. Use the provided tooling 😩😩😩

5. Putting in the effort to learn the frameworks your company is using

LET ME KNOW 🚀🚀🚀

Cypress and Page Object Pattern - Good practice for EndToEnd testing

Be consistent with the naming of your Attribute

Split up the test into a reusable Structure

Page Object Pattern

LET ME KNOW 🚀🚀🚀

Publish your own Docker Images with GitHub Actions

Prerequisites

Get Started with Docker

Write your first image

WorkFlow for automation

LET ME KNOW 🚀

5 Things I wished I had known when I started to maintain GitLab CICD

1. YAML Anchors

What are YAML Anchors?

2. Parallelization

3. CI_JOB_TOKEN

4. Clean Up Jobs

5. Child Pipelines & Dynamic Child Pipelines

LET ME KNOW 🚀

My favorite Laravel development environment, with Docker, Nginx, PHP-FPM Xdebug in VSCode

Table Of Content

Why should I use the set up

Requirements

Set up Guide

Break Down

Dockerfiles and Xdebug Configs

ENV Vars and docker-compose

NGINX Configs

Set Permissions

Redis Lib (optional)

First Run 🏁

Set Up VS Code

Troubleshooting

How to debug Laravel with XDebuger in VS Code

Install XDebug

Set Up VS Code

3. `CI_JOB_TOKEN`