By default, GitHub Actions allows multiple jobs within the same workflow, multiple workflow runs within the same repository, and multiple workflow runs across a repository owner’s account to run concurrently. This means that multiple workflow runs, jobs, or steps can run at the same time.
Have you ever encountered any of these challenges during your software development process!
Running Tests on Feature Branches
Scenario: your team is working on multiple feature branches, and each time code is pushed, a test suite is triggered on a CI environment.
Problem: when a developer pushes multiple commits in quick succession, tests will run for every push. However, the team is only interested in the test results for the latest commit.
Continuous Deployment to Production Environment
Scenario: you have a CI/CD pipeline that seamlessly deploys to the production environment as soon as changes are merged into the main branch.
Problem: multiple developers push updates to the repository in a short span, triggering multiple deployments to production. This could cause a race condition where one deployment overwrites another or causes downtime.
Allowing multiple pipeline executions simultaneously can lead to several potential drawbacks:
Duplicate workflows: multiple jobs run simultaneously for the same task (e.g., multiple deployments, tests, or builds), leading to redundant or wasted effort.
Resource waste: unnecessary consumption of CI/CD resources (e.g., CPU, memory, storage) due to running duplicate jobs or workflows.
Conflicts: jobs modifying the same resources or environments simultaneously, causing race conditions, inconsistent states, or overwriting each other’s work.
GitHub Actions also provides the flexibility to control concurrency with concurrency group, ensuring that only one workflow run, job, or step is executed at a time in specific contexts. This feature can be crucial for managing resources efficiently, avoiding conflicts, and preventing unexpected overuse of Actions minutes and storage when running multiple workflows simultaneously.
Therefore, with concurrency group,
Running Tests on Feature Branches can be enhanced with a concurrency group, which automatically cancels any ongoing tests when a new commit is pushed to the same branch. This ensures that only the most recent changes are evaluated.
Continuous Deployment to Production Environment can be streamlined by utilizing a concurrency group, which ensures that only one deployment is active at any given time for a specific environment. If a new commit is pushed, the current deployment can be canceled, allowing only the latest version to be deployed seamlessly.
To keep the AWSome Books project organized and tidy, it is a great idea to conduct experiments separately on a lighter codebase. Next, let’s run a series of experiments to compare the results with and without this feature. This way, we can clearly evaluate its impact!