Atomic Release: An all-or-nothing strategy to release code.

Elad Chen — Mon, 01 Nov 2021 17:25:30 +0000

Have you ever encountered a failure during a release process?
Did you have to "undo" steps taken before starting again?
If the answer to the above questions is yes, then keep reading.

The problem
A release process usually involves a series of automatic steps that must be performed to complete successfully, but what happens when a step fails?

If you want to start the release process with a clean slate
you have to determine which steps succeeded and "undo" whatever action they took… 😖

In other words, automated releases are rarely written to handle a failure, which means they leave a mess behind when a step fails halfway through.

The solution
Realising the above problem, I figured it can be solved
using the "Command" design pattern, and so atomic-release came into existence.

Today I'm happy to announce the first release of atomic-release
an NPM package that aims to help create automated releases using the command pattern.

The package is more of an SDK than a general-purpose solution, it has 2 core concepts and a reference implementation for releasing NPM packages.

Highlights:

TypeScript friendly.
APIs are loosely coupled. Use just what you need.
Can be used to automate the release of any project type.

Core concept #1 - "Strategy"

An abstract class that decides whether a release should be made, and
the commands to execute during a release.

Core concept #2 - "Command"

An abstract class with two methods, "do" which performs an action, and "undo" which undoes actions taken by the "do" method.

There are several pre-written commands available in the SDK.
See the commands docs for more details.

You can also write your own commands! Here are a few random ideas:

Slack: A command that notifies a slack channel of a successful release.
Jira: A command that comments on issues mentioned in the commits included in the release.
… Anything you can think of

*GithubNpmPackageStrategy
This strategy was created to illustrate an implementation of the SDK.

The strategy automates the release process end-to-end, it uses conventional commits to bump semantic versions, and generate change-logs.

Here's a demo showcasing a failure during a release and the undo taken:

See GithubNpmPackageStrategy for more details.

Fun fact:
The package itself is released using GithubNpmPackageStrategy 🤯

If you are interested in learning more, head over to the official repository.

As always, If you have any questions or feedback, please leave a comment below.

Protecting your Github workflows

Elad Chen — Fri, 09 Oct 2020 14:47:02 +0000

Have you ever tried to reveal a secret value stored in your continuous integration/delivery service? No? Well, maybe
someone else did.

Automation (or "CI") services… We are all using them, or at least should be they are the standard these days, and yet they are rarely given the attention they need.

Chapter One: Question Everything

I recently decided to use Github Actions to build, test, and release one of my Node.js open source projects, so I did what every developer would, I read the documentation and ran a few experiments, and soon after that, I realized that I'll have to store the NPM registry token as a secret to automate the release process.

Whenever I hear the word "secret" the following questions pop into my head:

"What will happen if the secret is revealed? Can it be revealed?"

Automation services are nothing new - I've worked for several companies throughout my career, and there was always some automation
service being used - point is, most secrets I've encountered in those automation services always gave me the chills because deep inside of me I knew if I can (and I could) turn them into plain text so does someone with malicious intents.

Chapter Two: The Quest For Answers

A quick search of my questions came up with a two very interesting read-ups and I recommend reading them, they describe the inherent vulnerability automation services introduce, and why they are a prime candidate when it comes to bug bounty programs

Shaking secrets out of CircleCI builds (I highly recommend reading this)
CI Knew There Would Be Bugs Here

Chapter Three: Making The World A Safer Place

Typically automation services are set up to act on any change happening throughout a codebase - whenever a change is pushed, a revision of the change will be fetched and executed.

Automation services (unlike me), do not have trust issues, especially when it comes to open source projects, because now, instead of trusting a limited number of actors, they trust any actor. 🤯

Before we discuss the solution, let's discuss the possible changes a malicious actor can do in a codebase - A Node.js project for example:

Adding a malicious module to the package.json dependencies
Modifying your workflows (.github/workflows/** ) to reveal secrets
Changing scripts that may be used during the build phase
…?

The above risks are relevant to any automation service and project type, not just Github Actions + Node.js project.
… Scary stuff if you ask me 🙀

So what can we expect from Github Actions? Not much.
The only thing worth mentioning is workflows that are triggered by a pull request will not have access to the original repository secrets.

The above is only partially true. Read the following announcement:
GitHub Actions improvements for fork and pull request workflows

Wouldn't it be nice if workflow runs could be monitored and even canceled under specific conditions? Actually, that is possible!

The solution: Protected Workflows

Protected Workflows is a Github Application
and is designed to cancel workflow runs by enforcing rules you configure, you can for example:

Specify user names who are allowed to trigger workflow runs
Specify file paths that may be changed
Specify paths that may not be changed (globs are supported as well)

Here is an example of how a config file may look like:

# Fallback rule in case nothing specific is set.
anyEvent:
 trustOrgMembers: true
 trustCollaborators: true
events:
  push: 
    - &basic_rule
      trustAnyone: true
      paths:
        disallowed:
          - ".github/**"
          - "package.json"
          - "package-lock.json"

  pull_request:
    - *basic_rule
  pull_request_target:
    - *basic_rule

The above config is using anchors, which is a useful YAML feature that enables re-using certain text blocks, and has a single rule defined ("basic_rule") used by events "push", "pull_request" and "pull_request_target".

The shared rule simply trusts any actor and will cancel workflow runs
in case certain paths were changed during the contextual event.

Its a wrap!

If you are interested in learning more, head over to the official documentation.

Thanks for taking the time to read this article! 🤓
If you have any questions or feedback, please leave a comment below.