Forem: Denis Gukov

I connected GitHub to Semaphore UI — and instantly fixed my dev workflow

Denis Gukov — Tue, 18 Nov 2025 08:39:22 +0000

For one of my customers, I use Semaphore UI to build and deploy a WordPress website.
The pipeline is simple: Build → Automatic deploy to DEV → Manual deploy to PROD.

The website code and the Ansible playbooks live in separate repositories, so I use a small Ansible task to clone the website repository:

- name: Update repo from {{ website_branch_prepared }}
  ansible.builtin.git:
    repo: git@github.com:*****/{{ slug }}.git
    force: true
    accept_hostkey: true
    version: "{{ website_branch_prepared }}"
    dest: "{{ tmp_dir.path }}"
    key_file: "{{ tmp_key_file.path }}"
  register: git_info

Since the source code is stored on GitHub, I use a GitHub webhook to trigger the Build task automatically on every commit.

The GitHub webhook calls the Semaphore Integration. Semaphore supports HMAC-based GitHub webhook authentication, so the setup is straightforward.

Everything worked well except for one issue:
I needed Semaphore to build the same branch that I pushed to, without manually updating the template configuration each time.

GitHub webhooks include the branch name in the ref field, but in this format:

refs/heads/<branch_name>

Semaphore Integrations can extract this field into a variable, but they do not modify or clean up the value.
To solve this, I added a simple Ansible task that prepares the branch name:

- name: Remove 'refs/heads/' prefix from branch name
  ansible.builtin.set_fact:
    website_branch_prepared: "{{ website_branch | regex_replace('^refs/heads/', '') }}"

And that's it — now everything works exactly as I need!

What's new in Ansible Semaphore 2.8.66

Denis Gukov — Sat, 01 Oct 2022 13:08:38 +0000

After half a year of waiting, the release of the Semaphore has finally come out. What's new in the much-anticipated release?

Dark mode

Color highlighting for Ansible output

Local playbooks

Previously Semaphore could only work with playbooks located in Git repositories. Support for local playbooks has been added in this version.

Simple CI/CD on Ansible Semaphore UI

Denis Gukov — Sat, 17 Sep 2022 09:48:04 +0000

CI/CD has become an important part of the software development process, both in large and small companies and projects, including open source.

The most popular CI/CD systems are GitLab and Jenkins. Both of these systems are powerful, expandable and include many additional features. With the help of these systems, you can build CI/CD of any complexity.

But it often happens, especially on small projects, that the most simple and straightforward solution is needed, rather than functionality. In this case, Ansible Semaphore is a good alternative to GitLab and Jenkins.

Ansible Semaphore is a web interface for running Ansible scripts with rudimentary CI/CD. With it, you can turn your playbook into a simple CI/CD system. This is an open source project that has been in development since 2015 and currently has 5200 stars on GitHub.

The Ansible Semaphore interface resembles that of Jenkins and AWX. The description of the interface can be found in the documentation.

The following assumes that the reader is familiar with Ansible.

For demo purposes will take the Trunk development model. Unlike Git-flow, this model assumes the same branch for development and production. This greatly simplifies CI/CD.

Our pipeline will look like this:

All elements of the scheme are easily implemented on Ansible. And thanks to versioning and scheduling of Ansible Semaphore, all this will work automatically.

Firstly, create a repository on GitHub

We need two playbooks and the corresponding roles for them:

build.yml - to build the application and send it to S3 storage.
deploy.yml - for delivering the application to the servers of the dev and production environments.

Here is the source code: github.com/fiftin/ansible-semaphore-deploy-test.

Web interface of Ansible Semaphore

For those who are familiar with AWX, the interface will be clear. For the rest I will briefly tell. The interface has the following key entities:

Task - The process of executing the Ansible playbook.
Task Template - the template on the basis of which the task is created.
Inventory - a list of servers for which the task will be performed.
Environment - environment variables (extra vars in Ansible terminology).
Key – SSH key or login/password that Ansible will use to connect to servers.
Repository - a git repository where the Ansible playbook code is stored.

Project setup

Let's create 3 Inventories (link):

Build - indicates on which server the application will be built.
Dev - a list of servers to which the application will be deployed in the dev environment.
Production - a list of servers to which the application will be deployed in the production environment.

Let's create 3 environments (link):

Build, Dev, Production.

Let's create 3 task templates (link):

Build - to build the application and send it to S3 storage.
Deploy to Dev - for delivering the application to the servers of the dev environment.
Deploy to Production - for delivering the application to the servers of the production environment.

We will deploy this simple web application: github.com/fiftin/ansible-semaphore-test-app :)

Launch

The Build task is executed automatically when a new commit appears in the repository. Successful builds are loaded into S3 storage.

After each successful build, the Deploy to Dev task is automatically launched, which deploys the application to the Dev environment. A demo dev site is available at demo-dev.ansible-semaphore.com.

You can play around with the above example at demo.ansible-semaphore.com.