DEV Community: kosei

A Practical Guide to Continuous Delivery with GitHub Actions and AWS CDK

kosei — Sun, 23 Feb 2025 15:41:23 +0000

Introduction

Previously, I wrote an article titled “Implementing Continuous Delivery for Monorepo and Microservice with GitHub Actions.” In this article, I would like to dive deeper into a pattern that utilizes AWS as the infrastructure.

Environment

In this article, the following tools will be used:

GitHub Actions
AWS Account
AWS CDK

Infrastructure Definition (IaC)

To perform Continuous Delivery (CD) on your infrastructure, you need to define your infrastructure as code (IaC). Although there are various tools available for IaC, here we will use AWS CDK.

AWS CDK

Since in my previous article the repository was set up assuming TypeScript, we will also configure AWS CDK with TypeScript. However, as this article focuses on CD, please refer to another article for detailed explanations on AWS CDK.

We aim for the following directory structure, so run the following command in the services/infrastructure directory:

./
├── .github/
│   └── workflows/
├── package.json
└── serivces/
    ├── infrastructure/
    ├── service-a/
    └── service-b/

Execute the following command to initialize AWS CDK:

npx aws-cdk init app --language typescript

This will generate the following files:

my-cdk-app/
├── bin/
│   └── infrastructure.ts
├── lib/
│   └── infrastructure-stack.ts
├── node_modules/
├── package.json
├── tsconfig.json
└── cdk.json

As a sample, the file infrastructure-stack.ts defines a stack that creates an S3 bucket:

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as s3 from 'aws-cdk-lib/aws-s3';

export class MyCdkAppStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Create an S3 Bucket
    new s3.Bucket(this, 'MyBucket', {
      bucketName: 'my-unique-bucket-name-12345', // ※ Change this to a globally unique name
      removalPolicy: cdk.RemovalPolicy.DESTROY, // Delete the bucket when the stack is deleted
      autoDeleteObjects: true, // Delete objects in the bucket if removalPolicy is DESTROY
    });
  }
}

Bootstrapping the Environment

Before the initial deployment, you must bootstrap the target AWS account and region so that AWS CDK can deploy your stack. If you need to deploy to multiple regions, perform the bootstrap for each region. Since this is a one-time process per AWS account and region, it does not need to be managed via CD (GitHub) and can be executed from your local development machine.

cdk bootstrap --region ap-northeast-1

Obtaining AWS Credentials

In order to deploy resources to AWS from GitHub Actions, you need to obtain credentials from AWS. Although you could use AWS_ACCESS_KEY and AWS_SECRET_KEY (i.e., access keys), there are several disadvantages to that approach, which is why the OIDC method described later is recommended:

Management cost of secrets
- Access keys require regular key rotation, leading to additional operational overhead.
Management cost for IAM users
- Since access keys are tied to IAM users, you would need to create IAM users for actions and periodically audit those accounts.
Security risks during operations
- Access keys are intended for long-term use, so if they are compromised, they can be misused for an extended period.
Inability for fine-grained control on AWS side
- AWS cannot restrict access based on the repository or branch when using access keys, and it is difficult to change permissions on a per-workflow basis.

Advantages of Using IAM Roles with OpenID Connect

When using AWS from GitHub Actions, obtaining a role session via OpenID Connect (OIDC) offers the following advantages:

No need to manage long-term credentials
- With OIDC, temporary credentials are issued for each session. This eliminates the need to manage access keys on GitHub, reducing the risk of key leakage and the burden of key rotation.
Increased security and minimal permissions
- Temporary sessions obtained via OIDC have short validity. Once the session expires, no further actions can be taken, significantly lowering the security risk. By creating an AWS IAM role with only the necessary permissions and obtaining a session for that role, you can minimize the risk of permission leakage.
Seamless integration between GitHub Actions and AWS
- You can restrict usage on a per-repository or per-branch basis—ensuring that only requests from specific repositories are valid, or even narrowing it down by branch or tag. Additionally, roles can be finely controlled per workflow (e.g., separate roles for deployment and testing), ensuring only the minimal required permissions are granted.

OIDC Configuration (AWS)

To accept OIDC tokens from GitHub Actions, you must create an OpenID Connect Provider on the AWS side.

Creating an IAM OIDC Provider with CDK

In CDK, you can use the OpenIdConnectProvider from the @aws-cdk/aws-iam module. Open your CDK stack file (e.g. lib/github-oidc-stack.ts) and modify it as follows:

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as iam from 'aws-cdk-lib/aws-iam';

export class CdkGithubOidcStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Create the GitHub OIDC Provider
    const gitHubOidcProvider = new iam.OpenIdConnectProvider(this, 'GitHubOidcProvider', {
      url: 'https://token.actions.githubusercontent.com',
      clientIds: ['sts.amazonaws.com'],
      thumbprints: ['6938fd4d98bab03faadb97b34396831e3780aea1'],
    });
  }
}

The parameters are set as follows:

url: Specify the GitHub Actions OIDC token endpoint:
- https://token.actions.githubusercontent.com
clientIds: Specify sts.amazonaws.com.
thumbprints: Specify the SHA-1 fingerprint of GitHub’s root certificate.
- Although it changed once in the past, it is currently 6938fd4d98bab03faadb97b34396831e3780aea1. This creates the OIDC provider required for federated authentication between GitHub and AWS.

Creating an IAM Role for Use from GitHub Actions

Creating the OIDC provider alone does not grant access to AWS resources. You also need to create an IAM role that GitHub Actions jobs can assume. In the role’s trust policy (assume role policy), you must specify that the entity possessing the GitHub Actions OIDC token is trusted.

Edit your CDK stack file (e.g. lib/github-oidc-stack.ts) as follows:

const githubRole = new iam.Role(this, 'GitHubActionsRole', {
  roleName: 'github-actions-deploy-role',
  assumedBy: new iam.WebIdentityPrincipal(
    gitHubOidcProvider.openIdConnectProviderArn,
    {
      StringEquals: {
        ['token.actions.githubusercontent.com:aud']: 'sts.amazonaws.com',
      },
      StringLike: {
        ['token.actions.githubusercontent.com:sub']: 'repo:your-org/your-repo:/*'
      }
    }
  ),

  // Actions allowed for this role (e.g., S3 management permissions)
  managedPolicies: [
    iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonS3FullAccess'),
    iam.ManagedPolicy.fromAwsManagedPolicyName('AWSCloudFormationFullAccess'),
  ],
});

Deploy the CDK stack and note the role ARN (e.g., arn:aws:iam::123456789012:role/github-actions-deploy-role).

Configuring GitHub Actions

After configuring AWS, you need to set up GitHub Actions to assume the IAM role. GitHub Actions provides an official AWS action, aws-actions/configure-aws-credentials, which supports OIDC.

You can choose the trigger conditions for the workflow; in this example, it will be triggered manually. For more details, see the GitHub documentation on manually running a workflow.

Finally, don’t forget to add the permissions section.

Your repository’s .github/workflows/deploy.yml file should be configured as follows:

name: Deploy to AWS

on:
  workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          # Specify the role ARN created earlier in CDK
          role-to-assume: arn:aws:iam::your-aws-account-id:role/github-actions-push-image-role
          aws-region: ap-northeast-1

      - name: Run deploy command
        run: npm run cdk deploy

role-to-assume: Specify the ARN of the IAM role you created.
aws-region: Specify the AWS region to use (e.g., ap-northeast-1).

This configuration automatically obtains an OIDC token, allowing GitHub Actions to use AWS CLI with a temporary STS session. Since there is no need to store access keys (AccessKey/SecretKey) in the repository secrets, the process is both more secure and reduces the key management burden.

Implementing Environment Switching and Approval Steps Using GitHub Environments

By using GitHub Environments, you can define settings and manage secrets for each environment (such as staging or production) and even implement an approval process.

For more details, see Managing Environments for Deployment.

Setting Up Environments

Within your GitHub repository, define environments such as “staging” and “production,” and configure secrets (e.g., AWS account, region, parameters) for each environment.

By setting up Required Reviewers, when a deployment workflow is executed, the workflow will pause until the specified reviewers approve it.

For example, if you define an environment called production, add the following to your workflow:

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: production # Specify the environment name to use

Switching Environments

Since you will likely use multiple environments, you may want to switch between environments like “staging” and “production” within the same workflow.

A workflow can accept an environment as an input, so you can switch environments (and thus the deployment target) by configuring it as follows:

on:
  workflow_dispatch:

inputs:
  env:
    description: AWS Environment
    required: true
    type: choice
    options:
      dev
      staging
      production

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: ${{ inputs.env }}
    steps:
      # ...

This allows you to dynamically switch settings such as the AWS account ID defined in GitHub environments, enabling you to manage multiple environments within a single workflow.

Additional Information

Extending the Session Duration

The AWS session obtained using the above configuration is valid for up to 1 hour. If your deployment workflow takes longer and the session expires, you can extend the session duration by adding additional settings to the role. For example:

const githubRole = new iam.Role(this, 'GitHubActionsRole', {
  roleName: 'github-actions-deploy-role',
  maxSessionDuration: cdk.Duration.hours(2), // Valid for 2 hours
  // ... other configurations
});

Implementing Continuous Delivery for Monorepo and Microservice with GitHub Actions

kosei — Sun, 17 Mar 2024 11:03:21 +0000

Introduction

In this article, we explore how to implement CD (Continuous Delivery) using GitHub Actions in a monorepo + microservices setup.

Prerequisites

This section outlines the language and directory structure used as prerequisites.

Language

The services within the repository are written in TypeScript and managed as workspaces with Yarn Workspaces. They are also assumed to be containerized. However, it is believed that the same mechanism could work even if services are written in different languages.

Directory Structure

The assumed directory structure is as follows: There is a services directory at the root, and each service is placed in its own directory within this.

Infrastructure management tools like AWS are also managed within the same repository, under services/infrastructure.

./
├── .github/
│   └── workflows/
├── package.json
└── serivces/
    ├── infrastructure/
    ├── service-a/
    └── service-b/

Problem

When adopting such a configuration, the scope of deployment becomes a problem. Workflows used in the repository are managed as common resources in .github/workflows, and if you write the deployment workflows for service-a and service-b there, deploying only service-a will inadvertently cause service-b to be deployed as well. This can lead to increased workflow execution times and, depending on the configuration, unnecessary deployment actions.

Solution

Therefore, let's consider a method to deploy only the services that have been changed.

Solution 1 (Using `paths` Filters)

A possible solution involves utilizing the functionality of including and excluding paths.

https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore

You can define the relevant paths as follows and prepare a workflow for each service accordingly.

For example, to deploy only service-a, the configuration might look like this:

name: Deploy service-a

on:
  push:
    paths:
      - 'serivces/service-a/**'

jobs:
  # Steps to deploy service-a go here

The disadvantages of this approach include the need to create a separate workflow file for each service, even when the deployment method is the same, which can make workflow file management cumbersome. Additionally, this method does not support dependencies between services.

Solution 2 (Using `git diff`)

Another method is to use Git's capabilities to deploy only the services that have been changed.

You can detect changes to the targeted services by using a command to get the differences from the last commit, and then deploy only the changed services.

Let's explore this approach further.

Architecture

The workflow will be documented for manual execution (workflow_dispatch), but it can also be set up to trigger automatically on push.

If there are changes to the overall infrastructure managed by IaC, you'll want to deploy those changes before deploying any services, considering the deployment dependencies. This setup should also accommodate dependencies between services, allowing them to be expressed in the same system.

Within the overall deployment workflow, implement the following jobs:

Change detection job (prepare)
Infrastructure deployment job
Individual service deployment jobs

This architecture allows for a more flexible deployment process, accommodating both the infrastructure and individual services, and addressing the need to manage dependencies between services.

graph TD;
    prepare-->infrastructure;
    infrastructure-->service-a;
    infrastructure-->service-b;

Indeed, having the ability to deploy services individually, in addition to deploying the entire system through one workflow, would offer greater flexibility and convenience. Thus, the solution should also enable workflows to deploy each service separately.

Detailed Workflow

Change Detection Job (`prepare`)

The change detection can be conducted as follows:

Use a script within the prepare job to run a git diff command against the last commit to identify changed paths.
Parse the output of the git diff command to determine which services have been modified. This could involve checking if the changes are within the directories specific to each service.
Set the output of this job to indicate which services need to be deployed. This can be achieved by setting environment variables or producing a file that subsequent jobs can read to determine whether they should proceed with deployment.

By implementing this job at the beginning of the workflow, you can dynamically decide which subsequent jobs (e.g., infrastructure deployment or individual service deployments) need to run based on the changes detected. This approach minimizes unnecessary deployments, saves time, and ensures that resources are used efficiently.

For individual service deployment workflows, you can adopt a similar change detection mechanism but scoped to the specific service's directory. This way, each service can have its workflow triggered either manually or automatically upon changes to its relevant files, offering a seamless and flexible deployment process tailored to the needs of each service within the monorepo.

jobs:
  prepare:
    outputs:
      infrastructure-diff-count: ${{ steps.infrastructure_changes.outputs.diff-count }}
      service-a-diff-count: ${{ steps.service_a_changes.outputs.diff-count }}
      service-b-diff-count: ${{ steps.service_b_changes.outputs.diff-count }}

    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 2
      - id: infrastructure_changes
        run: echo diff-count=`git diff HEAD~ --name-only --relative=services/infrastructure | wc -l` >> $GITHUB_OUTPUT
      - id: service_a_changes
        run: echo diff-count=`git diff HEAD~ --name-only --relative=services/service-a | wc -l` >> $GITHUB_OUTPUT
      - id: service_b_changes
        run: echo diff-count=`git diff HEAD~ --name-only --relative=services/service-b | wc -l` >> $GITHUB_OUTPUT

Here are the key point:

Point
Set fetch-depth to 2 in actions/checkout@v3

To obtain the differences from the previous commit using git diff HEAD~, you need to set the fetch-depth to 2. If this is not set, the previous commit cannot be fetched, and you will not be able to perform a diff comparison.
This precaution is essential because the default behavior of actions/checkout@v3 is to fetch only the latest commit (i.e., with a fetch-depth of 1). This shallow fetch is faster as it downloads less history, but it's not suitable for workflows that need to compare changes between commits. Setting fetch-depth to 2 ensures that the action fetches the last two commits, allowing git diff to correctly identify any changes made since the last commit. This setup is crucial for the change detection mechanism in CI/CD workflows that rely on comparing different versions of the codebase to determine the scope of changes and the necessity for deployments.

Infrastructure Deployment Job

We won't detail the infrastructure deployment code, but we will mainly mention the parts related to the previous job, the change detection job.

We define a deployment workflow for the infrastructure itself. By defining workflow_dispatch, we can execute the workflow for the infrastructure itself. Also, to make it callable from the overall workflow, we define workflow_call as well.

on:
  workflow_dispatch:
    inputs:
      stage:
        required: true
        type: string
  workflow_call:
    inputs:
      stage:
        required: true
        type: string

jobs:
  deploy:
    # setup, install, deploy, etc.
    # If using AWS CDK, deploy with commands like yarn workspace infrastructure cdk deploy --all --require-approval=never

Add the workflow to deploy the infrastructure itself to the overall deployment workflow.

jobs: # Written to align the indent, but it's the same job as prepare
  infrastructure_deploy:
    if: ${{ !cancelled() && !failure() && needs.prepare.outputs.infrastructure-diff-count > 0 }}
    needs:
      - prepare
    uses: '.github/workflows/deploy-infrastructure.yaml'
    with:
      stage: ${{ inputs.stage }}
    secrets: inherit

Here are the key points:

Point 1
Use if statements to determine the necessity of job execution

Use needs.prepare.outputs.infrastructure-diff-count > 0 to get the number of changed files obtained from the previous job and execute only if there are changes.

Point 2
Use needs to indicate dependencies
needs: 
  - prepare
shows that it depends on the prepare job. It is possible to specify multiple dependencies, which can represent waiting until the deployment of the infrastructure or another dependent service is completed.

Point 3
Call the individual infrastructure workflow with uses

You can call another workflow set up with workflow_call using uses: path to workflow file. If secrets are needed, they can be passed when calling. Specifying inherit allows passing them collectively, but it's also possible to specify them individually.

Deployment Jobs for Each Service

The deployment jobs for each service are almost the same as those for deploying infrastructure, so only the key points are described.

We define a deployment workflow for each individual service. Services that can be deployed with the same workflow will reuse that workflow by accepting the service name as input.

on:
  workflow_dispatch:
    inputs:
      stage:
        required: true
        type: string
      service:
       required: true
       type: choice
       options:
         - service-a
         - service-b
  workflow_call:
    inputs:
      stage:
        required: true
        type: string
      service:
       required: true
       type: string

jobs:
  deploy:
    # setup, install, deploy, etc.
    # The workflow is reused by switching the target service based on inputs.service

Add the workflow for deploying individual infrastructure to the overall deployment workflow.

jobs: # Written to align the indentation, but it's the same job as prepare
  service_a_deploy:
    if: ${{ !cancelled() && !failure() && needs.prepare.outputs.service-a-diff-count > 0 }}
    needs:
      - prepare
      - infrastructure_deploy
    uses: '.github/workflows/deploy-service.yaml'
    with:
      stage: ${{ inputs.stage }}
      service: service-a
    secrets: inherit

  service_b_deploy:
    if: ${{ !cancelled() && !failure() && needs.prepare.outputs.service-b-diff-count > 0 }}
    needs:
      - prepare
      - infrastructure_deploy
      # - service_a_deploy
      # If dependent on service-a, specify as above to wait for the completion of service-a's deployment
    uses: '.github/workflows/deploy-service.yaml'
    with:
      stage: ${{ inputs.stage }}
      service: service-b
    secrets: inherit

The key point is as follows:

Point
Add cancelled(), failure() to the if statement to determine whether to execute the job

Add !cancelled() && !failure() && to the conditions of the if statement. This is to ensure that the workflow stops if it is cancelled, and also to ensure that this job does not skip if the jobs it depends on are skipped.

Summary

With GitHub monorepo + microservices, it was possible to deploy only the services that have changes. The triggers for the workflow and the conditions for detecting changes can be adjusted according to each project.

Conditional Branching with workflow_dispatch and workflow_call in GitHub Actions

kosei — Fri, 08 Mar 2024 17:41:05 +0000

Introduction

There's a feature in GitHub Actions for reusing workflows. With workflow reuse, you can call another workflow from a workflow.

https://docs.github.com/en/actions/using-workflows/reusing-workflows

In doing so, there was a need to branch depending on whether the called workflow was called from another workflow, or if the workflow was executed standalone. This article describes how to do that.

How to

In GitHub Actions, you can obtain various information from the context at runtime.

https://docs.github.com/en/actions/learn-github-actions/contexts

Among these, there exists a key named github.event.workflow. This value contains the file path of the workflow.

Depending on how it was called, the called workflow can obtain the following values (in the case where workflowA calls workflowB):

When executing workflowB directly (workflow_dispatch), the value of github.event.workflow
The file path of workflowB (.github/workflows/workflow-b.yaml)
When executed from workflowA (workflow_call), the value of github.event.workflow
The file path of workflowA (.github/workflows/workflow-a.yaml)
With this, you can branch your process or steps.

For example, if you want to execute a step only when workflowB is executed directly, you can add the following condition:

if: github.event.workflow == '.github/workflows/workflow-b.yaml'

There's also a github.event_name, and I tried to see if it could be used for branching as well, but both the direct execution of workflowB and the execution from workflowA resulted in the same value as workflow_dispatch, so it couldn't be used for branching.

About type: environment

In practice, I think you can use the same workflow without branching by defining inputs with the same name as below, but since type: environment exists only for workflow_dispatch, if you are using this, you'll need to add a step to absorb the difference.

on:
  workflow_dispatch:
    inputs:
      input1:
        required: true
        type: string    
  workflow_call:
    inputs:
      input1:
        required: true
        type: string

The value in the environment (environment_name) can be used as is, but as shown above, this difference occurs, so it seems better to avoid it when making a workflow_call.

Summary

There seem to be various methods, but by checking github.event.workflow, we were able to branch based on the method of executing the workflow.

How to Set Dynamic Release URLs in Environment with GitHub Actions

kosei — Thu, 07 Mar 2024 16:50:10 +0000

Introduction

This article explains how to dynamically set a release URL in an Environment using GitHub Actions.

Background

GitHub Actions has a feature for defining environments called Environment.
Using environments for deployment - GitHub

For example, by setting up environments like the following, it's possible to switch the release destination. (You can set any name you want.)

Production environment
Staging environment
Testing environment
Development environment

Among these, there is a function to display the URL of the release destination after releasing.

If there's only one fixed environment, it's not a problem. However, if the URL is determined dynamically during the release steps, it was unclear how to display it, so I'm documenting the method here.

If it's a single environment, you can set the URL as follows.



environment:

    name: production

    url: https://example.com

How To

The method is simple: save the value in an output during the step when the URL is confirmed, and then set that output as the environment's URL.

Here is a sample Yaml. You need to assign a reference ID to the step. The format for referencing the output is steps.[step_id].outputs.[output_name].



environment:

    name: development

    url: ${{ steps.get_release_url.outputs.release_url }}

steps:

    - name: Set release url

      id: get_release_url

      run: echo release_url=https://xxx.example.com >> $GITHUB_OUTPUT

Conclusion

The method to dynamically set the URL of a release in GitHub Actions' Environment is to save a value in the output during the release step, and then set that output name as the URL in the environment.

Removing "✨ Done in X.XXs." with Yarn

kosei — Wed, 06 Mar 2024 16:33:56 +0000

Introduction

I wanted to remove the "✨ Done in X.XXs." message in Yarn. In the package.json, I defined the following:

{
  "scripts": {
    "echo": "echo aaa"
  }
}

When executed, it displays the "✨ Done in X.XXs." message.

$ yarn run echo
yarn run v1.22.10
$ echo aaa
aaa
✨  Done in 0.04s.

--silent Option

By adding the --silent option, it disappeared.

$ yarn run --silent echo
aaa

How to Reset Your User Password in Ubuntu on WSL if You Forget It

kosei — Tue, 05 Mar 2024 15:31:09 +0000

Introduction

After a long time, I tried to launch WSL and sudo on Ubuntu, but I forgot the password.

Reset Method

wsl -u root

Enter the username you want to reset in place of [username] in the following command.
You will be prompted for a new password, so reset it.

passwd [username]

DEV Community: kosei

A Practical Guide to Continuous Delivery with GitHub Actions and AWS CDK

Introduction

Environment

Infrastructure Definition (IaC)

AWS CDK

Bootstrapping the Environment

Obtaining AWS Credentials

Advantages of Using IAM Roles with OpenID Connect

OIDC Configuration (AWS)

Creating an IAM OIDC Provider with CDK

Creating an IAM Role for Use from GitHub Actions

Configuring GitHub Actions

Implementing Environment Switching and Approval Steps Using GitHub Environments

Setting Up Environments

Switching Environments

Additional Information

Extending the Session Duration

Implementing Continuous Delivery for Monorepo and Microservice with GitHub Actions

Introduction

Prerequisites

Language

Directory Structure

Problem

Solution

Solution 1 (Using paths Filters)

Solution 2 (Using git diff)

Architecture

Detailed Workflow

Change Detection Job (prepare)

Infrastructure Deployment Job

Deployment Jobs for Each Service

Summary

Conditional Branching with workflow_dispatch and workflow_call in GitHub Actions

Introduction

How to

About type: environment

Summary

How to Set Dynamic Release URLs in Environment with GitHub Actions

Introduction

Background

How To

Conclusion

Removing "✨ Done in X.XXs." with Yarn

Introduction

--silent Option

How to Reset Your User Password in Ubuntu on WSL if You Forget It

Introduction

Reset Method

Solution 1 (Using `paths` Filters)

Solution 2 (Using `git diff`)

Change Detection Job (`prepare`)