Solving the “Works on my Machine” Problem
May 9, 2024
Case Study
We’re always interested in hearing how our community is using Dagger – their use cases, their challenges, and their experiences with deploying Dagger in different environments. Our Discord is a great place to find these stories, and to benefit from the knowledge and experience of the Dagger community.
In this blog post, we’ll share the story of Daggernaut Emmanuel Sibanda (aka @emmzw on Discord). Emmanuel is a software engineer who enjoys building tools to solve everyday problems and testing open source tools that have practical value. He is also the developer of an open-source application that helps people prepare for technical interviews. Previously, Emmanuel was plagued by the “works on my machine” problem for his application’s unit tests…but he was able to eliminate this problem completely by using Dagger in his production CI pipeline.
“The phrase 'Dagger enables you to run pipelines anywhere' sounded good, but it started to make sense, when I realized this meant I could run parts of my test pipeline locally with consistency allowing for quicker feedback.” - Emmanuel Sibanda
Development friction from inconsistent, slow CI environments
Emmanuel's application helps people prepare for technical interviews on data structures and algorithms, with additional guidance from AI. The application’s CI pipeline runs multiple tasks, including linting and formatting the code, running unit tests, and creating Docker images.
Initially, the application's CI pipeline was built entirely in GitHub Actions. As a result, unit tests would only be triggered when new code was committed and pushed to GitHub. This added time and friction to the development process: Emmanuel needed to wait after every push to see if the build was successful. Another issue was inconsistency between local and CI environments: sometimes, tests would pass when run locally but fail when pushed to GitHub.
To resolve these issues, Emmanuel explored various solutions, including writing scripts to run unit tests locally and using act to run GitHub Actions workflows locally. However, neither approach could guarantee the consistency he was looking for between local and remote CI runs.
"I would have my tests passing locally, but sometimes not passing in production. Also, it required me to actually push code to my repo to run my test. This was delaying the feedback loop of correcting the code."
Faster, more consistent CI runs with Dagger Functions
Emmanuel discovered Dagger in January 2024 and realized it was the solution he was searching for. He began exploring Dagger and the Daggerverse, and was excited to learn that he could build his pipeline as a reusable Dagger module. In March 2024, after spending some time experimenting with Dagger Functions, he replaced the unit testing segment of his GitHub Actions workflow with a Dagger Function.
Even though Emmanuel has only "Daggerized" a part of the CI pipeline, he is already seeing multiple benefits from the change.
Quicker feedback loop: A Dagger Function can be invoked locally. This means that, instead of pushing code to GitHub and waiting to see if unit tests succeed, Emmanuel now receives almost-immediate feedback on each local test run.
Consistent CI environments: Dagger Functions are environment-agnostic, because they perform all their tasks in containers. Emmanuel no longer needs to manage or work around differences between local and remote CI environments.
Pipeline maintainability: Emmanuel’s Dagger Function is written in Python. This makes it easier to maintain, understand and improve. Since Dagger Functions are written entirely in code, Emmanuel was able to easily build conditional logic into his CI pipeline, which was not possible with the previous GitHub Actions workflow.
"Now, wherever, whenever I run this Dagger Function, I know that if my tests are passing, they're passing everywhere, in every environment."
End-to-end Dagger Functions for CI
Emmanuel is happy with the results so far and is using Dagger in his production CI pipeline. He plans to replace the current GitHub Actions workflow entirely with Dagger replacing his CI pipeline with Dagger Functions. Module reusability is also of keen interest to him, as he intends to reuse his Dagger Functions in his other projects too.
"If I'm going to be building different parts of my pipeline as modules, I want to reuse them in other projects. With Dagger, it is easy for me to just write one module to be used in multiple places."
Do you have a Dagger story you’d like us to feature? Tell us all about it in Discord!
We’re always interested in hearing how our community is using Dagger – their use cases, their challenges, and their experiences with deploying Dagger in different environments. Our Discord is a great place to find these stories, and to benefit from the knowledge and experience of the Dagger community.
In this blog post, we’ll share the story of Daggernaut Emmanuel Sibanda (aka @emmzw on Discord). Emmanuel is a software engineer who enjoys building tools to solve everyday problems and testing open source tools that have practical value. He is also the developer of an open-source application that helps people prepare for technical interviews. Previously, Emmanuel was plagued by the “works on my machine” problem for his application’s unit tests…but he was able to eliminate this problem completely by using Dagger in his production CI pipeline.
“The phrase 'Dagger enables you to run pipelines anywhere' sounded good, but it started to make sense, when I realized this meant I could run parts of my test pipeline locally with consistency allowing for quicker feedback.” - Emmanuel Sibanda
Development friction from inconsistent, slow CI environments
Emmanuel's application helps people prepare for technical interviews on data structures and algorithms, with additional guidance from AI. The application’s CI pipeline runs multiple tasks, including linting and formatting the code, running unit tests, and creating Docker images.
Initially, the application's CI pipeline was built entirely in GitHub Actions. As a result, unit tests would only be triggered when new code was committed and pushed to GitHub. This added time and friction to the development process: Emmanuel needed to wait after every push to see if the build was successful. Another issue was inconsistency between local and CI environments: sometimes, tests would pass when run locally but fail when pushed to GitHub.
To resolve these issues, Emmanuel explored various solutions, including writing scripts to run unit tests locally and using act to run GitHub Actions workflows locally. However, neither approach could guarantee the consistency he was looking for between local and remote CI runs.
"I would have my tests passing locally, but sometimes not passing in production. Also, it required me to actually push code to my repo to run my test. This was delaying the feedback loop of correcting the code."
Faster, more consistent CI runs with Dagger Functions
Emmanuel discovered Dagger in January 2024 and realized it was the solution he was searching for. He began exploring Dagger and the Daggerverse, and was excited to learn that he could build his pipeline as a reusable Dagger module. In March 2024, after spending some time experimenting with Dagger Functions, he replaced the unit testing segment of his GitHub Actions workflow with a Dagger Function.
Even though Emmanuel has only "Daggerized" a part of the CI pipeline, he is already seeing multiple benefits from the change.
Quicker feedback loop: A Dagger Function can be invoked locally. This means that, instead of pushing code to GitHub and waiting to see if unit tests succeed, Emmanuel now receives almost-immediate feedback on each local test run.
Consistent CI environments: Dagger Functions are environment-agnostic, because they perform all their tasks in containers. Emmanuel no longer needs to manage or work around differences between local and remote CI environments.
Pipeline maintainability: Emmanuel’s Dagger Function is written in Python. This makes it easier to maintain, understand and improve. Since Dagger Functions are written entirely in code, Emmanuel was able to easily build conditional logic into his CI pipeline, which was not possible with the previous GitHub Actions workflow.
"Now, wherever, whenever I run this Dagger Function, I know that if my tests are passing, they're passing everywhere, in every environment."
End-to-end Dagger Functions for CI
Emmanuel is happy with the results so far and is using Dagger in his production CI pipeline. He plans to replace the current GitHub Actions workflow entirely with Dagger replacing his CI pipeline with Dagger Functions. Module reusability is also of keen interest to him, as he intends to reuse his Dagger Functions in his other projects too.
"If I'm going to be building different parts of my pipeline as modules, I want to reuse them in other projects. With Dagger, it is easy for me to just write one module to be used in multiple places."
Do you have a Dagger story you’d like us to feature? Tell us all about it in Discord!
We’re always interested in hearing how our community is using Dagger – their use cases, their challenges, and their experiences with deploying Dagger in different environments. Our Discord is a great place to find these stories, and to benefit from the knowledge and experience of the Dagger community.
In this blog post, we’ll share the story of Daggernaut Emmanuel Sibanda (aka @emmzw on Discord). Emmanuel is a software engineer who enjoys building tools to solve everyday problems and testing open source tools that have practical value. He is also the developer of an open-source application that helps people prepare for technical interviews. Previously, Emmanuel was plagued by the “works on my machine” problem for his application’s unit tests…but he was able to eliminate this problem completely by using Dagger in his production CI pipeline.
“The phrase 'Dagger enables you to run pipelines anywhere' sounded good, but it started to make sense, when I realized this meant I could run parts of my test pipeline locally with consistency allowing for quicker feedback.” - Emmanuel Sibanda
Development friction from inconsistent, slow CI environments
Emmanuel's application helps people prepare for technical interviews on data structures and algorithms, with additional guidance from AI. The application’s CI pipeline runs multiple tasks, including linting and formatting the code, running unit tests, and creating Docker images.
Initially, the application's CI pipeline was built entirely in GitHub Actions. As a result, unit tests would only be triggered when new code was committed and pushed to GitHub. This added time and friction to the development process: Emmanuel needed to wait after every push to see if the build was successful. Another issue was inconsistency between local and CI environments: sometimes, tests would pass when run locally but fail when pushed to GitHub.
To resolve these issues, Emmanuel explored various solutions, including writing scripts to run unit tests locally and using act to run GitHub Actions workflows locally. However, neither approach could guarantee the consistency he was looking for between local and remote CI runs.
"I would have my tests passing locally, but sometimes not passing in production. Also, it required me to actually push code to my repo to run my test. This was delaying the feedback loop of correcting the code."
Faster, more consistent CI runs with Dagger Functions
Emmanuel discovered Dagger in January 2024 and realized it was the solution he was searching for. He began exploring Dagger and the Daggerverse, and was excited to learn that he could build his pipeline as a reusable Dagger module. In March 2024, after spending some time experimenting with Dagger Functions, he replaced the unit testing segment of his GitHub Actions workflow with a Dagger Function.
Even though Emmanuel has only "Daggerized" a part of the CI pipeline, he is already seeing multiple benefits from the change.
Quicker feedback loop: A Dagger Function can be invoked locally. This means that, instead of pushing code to GitHub and waiting to see if unit tests succeed, Emmanuel now receives almost-immediate feedback on each local test run.
Consistent CI environments: Dagger Functions are environment-agnostic, because they perform all their tasks in containers. Emmanuel no longer needs to manage or work around differences between local and remote CI environments.
Pipeline maintainability: Emmanuel’s Dagger Function is written in Python. This makes it easier to maintain, understand and improve. Since Dagger Functions are written entirely in code, Emmanuel was able to easily build conditional logic into his CI pipeline, which was not possible with the previous GitHub Actions workflow.
"Now, wherever, whenever I run this Dagger Function, I know that if my tests are passing, they're passing everywhere, in every environment."
End-to-end Dagger Functions for CI
Emmanuel is happy with the results so far and is using Dagger in his production CI pipeline. He plans to replace the current GitHub Actions workflow entirely with Dagger replacing his CI pipeline with Dagger Functions. Module reusability is also of keen interest to him, as he intends to reuse his Dagger Functions in his other projects too.
"If I'm going to be building different parts of my pipeline as modules, I want to reuse them in other projects. With Dagger, it is easy for me to just write one module to be used in multiple places."
Do you have a Dagger story you’d like us to feature? Tell us all about it in Discord!
