arturz

Why opening a PR turns your source branch red in GitHub Actions

Tue, 17 Feb 2026 07:30:00 GMT

Introduction

Imagine the following scenario: you merge the latest changes to the main branch, and CI passes ✅. Everything's looking good!

You have a standard GitHub Actions workflow that runs CI on every push and pull request on both main and staging branches:

on:
  pull_request:
    branches: [ main, staging ]
  push:
    branches: [ main, staging ]

You also have a CD configured that automatically deploys the latest changes from staging branch, so you create a PR to merge changes from main to staging to live test new features in the staging environment.

Suddenly, CI status on the main branch changes from ✅ to ❌️.

What happened?

You see that the PR failed. GitHub Actions attaches check results to commit hashes, not branches. The status you see on a branch is the status of its latest commit, and since your main branch and new PR both point to the same commit, the PR's check failure shows up on main too.

If you go into failure details on your main branch, you'll see both checks:

❌️ CI / build (pull_request)
✅ CI / build (push)

And because at least one of them is failing, the whole check is red.

What can be done about it

A modern DevOps industry standard is to use the Build Once, Deploy Anywhere pattern instead of environment branching to deploy to different environments.

But there are a lot of legacy codebases and simpler setups out there, and there's no simple solution that does not have its trade-off.

You can create a GitHub branch protection rule to only require a push check on main for passing ✅. But by the time someone creates a new check, let's say for E2E tests, you will likely have forgotten about this rule, and it won't show on main as a failure ❌️ until someone notices. Right now, it's not possible to create a rule that requires all checks except pull_request.

You can also configure your GitHub Actions workflow not to run checks on PRs to staging, but then you'll find out about errors only after they are merged into staging.

Resolution

After fixing failing CI on new PR and rerunning checks (or after merging it and pushing new commits to main branch), the old pull_request check is overwritten and main turns green again ✅.

TIL: Ecto preload with a custom query

Thu, 05 Feb 2026 20:00:00 GMT

Sometimes you may want to pass a custom query to preload function.

There're department with employees schemata that can be soft-deleted:

# Department schema
defmodule HR.Department do
  use Ecto.Schema

  schema "departments" do
    field :name, :string
    has_many :employees,
      HR.Employee,
      where: [deleted_at: nil]
    timestamps()
  end
end

# Employee schema
defmodule HR.Employee do
  use Ecto.Schema

  schema "employees" do
    field :email, :string
    field :deleted_at, :utc_datetime_usec
    belongs_to :department, HR.Department
    timestamps()
  end
end

Let's say we want to get department info with all employees, including those that were deleted.

❌️ We cannot just preload it, because has_many field has where: [deleted_at: nil] filtering association.

HR.Department
|> preload([_department], :employees)

❌️ You can pass custom query to preload via joined binding, but it won't work if you use the assoc macro which respects filtering associations.

HR.Department
|> join(:left, [department], employees in assoc(department, :employees))
|> preload([_department], {employees, :employees})

✅ Instead, you need to build your joined binding from scratch:

HR.Department
|> join(:left, [department], employees in HR.Employee, on: department.id == employee.department_id)
|> preload([_department], {employees, :employees})

Introducing Kanta - Translations for Elixir & Phoenix

Tue, 05 Sep 2023 00:00:00 GMT

Handling translations in web applications can be a challenging and time-consuming task. The process entails managing various files, tracking modifications, and ensuring that translations remain current as the project progresses. These complexities can slow down development and introduce errors. That's why we decided to create an open source solution: Kanta.

In this blog post, we'll explore the problem of managing translations in web apps, and how Kanta simplifies the process. We'll also compare it with other translation management tools and delve into its powerful plugins.

What does AI dream about? Stable Diffusion in Elixir

Mon, 06 Mar 2023 00:00:00 GMT

Tools like ChatGPT and DALL·E2 brought immense interest to AI. The go-to language to work with machine learning and artificial intelligence is Python, but market share may shift thanks to some tools created recently in Elixir programming language.

TIL: Check if Elixir map has a key in a guard

Thu, 22 Dec 2022 00:00:00 GMT

Today's Advent of Code puzzle inspired me to create this TIL. It may sound trivial, but in fact, it's tricky if you are unfamiliar with the nuances of guards' functioning.

How to program an IoT device in Elixir using Nerves

Sat, 30 Jul 2022 00:00:00 GMT

Elixir is a great choice language for IoT devices due to its fault-tolerant nature, but also because of the ability to handle a lot of concurrent I/O operations thanks to the BEAM scheduler running under the hood.