DevOps

2 posts with the tag “DevOps”

How to Automate Steam Releases with GitHub Actions

Apr 16, 2026

How to Automate Steam Releases with GitHub Actions

This article shares the complete solution we implemented for automated Steam releases in the HagiCode Desktop project, covering the end-to-end automation flow from GitHub Release to the Steam platform, including key technical details such as Steam Guard authentication and multi-platform Depot uploads.

Background

The release workflow on Steam is actually quite different from traditional application distribution. Steam has its own complete update delivery system. Developers need to use SteamCMD to upload build artifacts to Steam’s CDN network, rather than simply dropping in a download link like on other platforms.

The HagiCode Desktop project is preparing for a Steam release, which introduced a few new challenges to our release workflow:

We needed to convert existing build artifacts into a Steam-compatible format.
We had to upload them to Steam through SteamCMD.
We also had to handle Steam Guard authentication.
We needed to support multi-platform Depot uploads for Linux, Windows, and macOS.
We wanted a fully automated flow from GitHub Release to Steam.

The project had already implemented “portable version mode,” which allows the application to detect fixed service payloads packaged in the extra directory. Our goal was to integrate that portable version mode seamlessly with Steam distribution.

About HagiCode

The solution shared in this article comes from our practical experience in the HagiCode project. HagiCode is an AI coding assistant that supports desktop usage. Since we are actively working toward launching on Steam, we needed to establish a reliable automated release workflow.

Architecture Design

The core of the entire Steam release process is a GitHub Actions workflow that divides the process into three main stages:

┌─────────────────────────────────────────────────────────────┐
│ GitHub Actions Workflow (Steam Release)                    │
├─────────────────────────────────────────────────────────────┤
│ 1. Preparation Stage:                                      │
│    - Check out portable-version code                       │
│    - Download build artifacts from GitHub Release          │
│    - Extract and prepare the Steam content directory       │
│                                                             │
│ 2. SteamCMD Setup:                                         │
│    - Install or reuse SteamCMD                             │
│    - Authenticate with Steam Guard                         │
│                                                             │
│ 3. Release Stage:                                          │
│    - Generate Depot VDF configuration files                │
│    - Generate App Build VDF configuration files            │
│    - Invoke SteamCMD to upload to Steam                    │
└─────────────────────────────────────────────────────────────┘

This design offers several advantages:

It reuses existing GitHub Release artifacts and avoids rebuilding the same outputs.
It uses self-hosted runners for secure isolation.
It supports switching between preview mode and formal release branches.
It includes complete error handling and logging, which makes failures easier to diagnose.

Workflow Implementation

Trigger Parameter Design

Our workflow supports the following key parameters:

inputs:
  release:           # Portable Version release tag
    description: 'Version tag to release (for example v1.0.0)'
    required: true
  steam_preview:     # Whether to generate a preview build
    description: 'Whether to use preview mode'
    required: false
    default: 'false'
  steam_branch:      # Steam branch to set live
    description: 'Target Steam branch'
    required: false
    default: 'preview'
  steam_description: # Build description override
    description: 'Build description'
    required: false

Self-hosted Runner Configuration

For security reasons, we use a self-hosted runner with the steam label:

runs-on:
  - self-hosted
  - Linux
  - X64
  - steam

This ensures that Steam releases run on a dedicated runner and keeps sensitive credentials safely isolated.

Concurrency Control

To prevent releases of the same version from interfering with each other, we configured concurrency control:

concurrency:
  group: portable-version-steam-${{ github.event.inputs.release }}
  cancel-in-progress: false

Notice that cancel-in-progress: false is set here because Steam releases can take a while, and we do not want a newly triggered run to cancel one that is already uploading.

Core Script Implementation

Preparing Release Inputs

The prepare-steam-release-input.mjs script is responsible for preparing the inputs required for release:

// Download the GitHub Release build manifest and artifact inventory
const buildManifest = await downloadBuildManifest(releaseTag);
const artifactInventory = await downloadArtifactInventory(releaseTag);

// Download compressed archives for each platform
for (const platform of ['linux-x64', 'win-x64', 'osx-universal']) {
  const artifactUrl = getArtifactUrl(artifactInventory, platform);
  await downloadArtifact(artifactUrl, platform);
}

// Extract into the Steam content directory structure
await extractToSteamContent(sources, contentRoot);

Steam Guard Authentication

Steam requires accounts to be protected with Steam Guard, so we implemented a shared-secret-based code generation algorithm:

function generateSteamGuardCode(sharedSecret, timestamp = Date.now()) {
  const secret = decodeSharedSecret(sharedSecret);
  const time = Math.floor(timestamp / 1000 / 30);

  const timeBuffer = Buffer.alloc(8);
  timeBuffer.writeBigUInt64BE(BigInt(time));

  // Use HMAC-SHA1 to generate a time-based one-time code
  const hash = crypto.createHmac('sha1', secret)
    .update(timeBuffer)
    .digest();

  // Convert it into a 5-character Steam Guard code
  const code = steamGuardCode(hash);
  return code;
}

This implementation is based on Steam Guard’s TOTP (Time-based One-Time Password) mechanism, generating a new verification code every 30 seconds.

VDF Configuration Generation

VDF (Valve Data Format) is the configuration format used by Steam. We need to generate two types of VDF files:

Depot VDF is used to configure content for each platform:

function buildDepotVdf(depotId, contentRoot) {
  return [
    '"DepotBuildConfig"',
    '{',
    `  "DepotID" "${escapeVdf(depotId)}"`,
    `  "ContentRoot" "${escapeVdf(contentRoot)}"`,
    '  "FileMapping"',
    '  {',
    '    "LocalPath" "*"',
    '    "DepotPath" "."',
    '    "recursive" "1"',
    '  }',
    '}'
  ].join('\n');
}

App Build VDF is used to configure the entire application build:

function buildAppBuildVdf(appId, depotBuilds, description, setLive) {
  const vdf = [
    '"appbuild"',
    '{',
    `  "appid" "${appId}"`,
    `  "desc" "${escapeVdf(description)}"`,
    `  "contentroot" "${escapeVdf(contentRoot)}"`,
    '  "buildoutput" "build_output"',
    '  "depots"',
    '  {'
  ];

  for (const [depotId, depotVdfPath] of Object.entries(depotBuilds)) {
    vdf.push(`    "${depotId}" "${depotVdfPath}"`);
  }

  if (setLive) {
    vdf.push(`  }`);
    vdf.push(`  "setlive" "${setLive}"`);
  }

  vdf.push('}');
  return vdf.join('\n');
}

SteamCMD Invocation

Finally, the upload is performed by invoking SteamCMD:

await runCommand(steamcmdPath, [
  '+login', steamUsername, steamPassword, steamGuardCode,
  '+run_app_build', appBuildPath,
  '+quit'
]);

This is the final jump in the whole workflow. Once it succeeds, the release is done.

Multi-platform Depot Handling

Steam uses the Depot system to manage content for different platforms. We support three main Depots:

Platform	Depot Identifier	Architecture Support
Linux	`linux-x64`	x64_64
Windows	`win-x64`	x64_64
macOS	`osx-universal`	universal, x64_64, arm64

Each Depot has its own content directory and VDF configuration file. This ensures that users on different platforms only download the content they actually need.

Release Workflow

Step 1: Prepare the GitHub Release

First, create a GitHub Release in the portable-version repository that includes:

Compressed archives for each platform
Build manifest ({tag}.build-manifest.json)
Artifact inventory ({tag}.artifact-inventory.json)

Step 2: Trigger the Steam Release Workflow

Trigger the workflow manually through GitHub Actions and fill in the required parameters:

release: the version tag to publish, such as v1.0.0
steam_branch: the target branch, such as preview or public
steam_preview: whether to use preview mode

Step 3: Execute the Release Flow Automatically

The workflow automatically performs the following steps:

Download and extract GitHub Release artifacts.
Install or update SteamCMD.
Generate Steam VDF configuration files.
Authenticate with Steam Guard.
Upload content to the Steam CDN.
Set the specified branch live.

Once this sequence completes, the whole release path is covered.

Configuration Guide

Required Secrets Configuration

Configure the following secrets in the GitHub repository settings:

Secret Name	Description
`STEAM_USERNAME`	Steam account username
`STEAM_PASSWORD`	Steam account password
`STEAM_SHARED_SECRET`	Steam Guard shared secret (optional)
`STEAM_GUARD_CODE`	Steam Guard code (optional)
`STEAM_APP_ID`	Steam application ID
`STEAM_DEPOT_ID_LINUX`	Linux Depot ID
`STEAM_DEPOT_ID_WINDOWS`	Windows Depot ID
`STEAM_DEPOT_ID_MACOS`	macOS Depot ID

There is nothing especially unusual about these settings. You simply need all of the expected values in place.

Environment Variable Configuration

Variable Name	Description	Default Value
`PORTABLE_VERSION_STEAMCMD_ROOT`	SteamCMD installation directory	`~/.local/share/portable-version/steamcmd`

Best Practices

Steam Guard Authentication Management

On the first run, you need to enter the Steam Guard code manually. After that, it is recommended to configure the shared secret so the code can be generated automatically. This avoids manual intervention on every release.

SteamCMD saves the login token and can reuse it on later runs. You still need to keep an eye on token expiration, because re-authentication is required after the token expires.

Content Directory Structure

Make sure the Steam content directory structure is correct:

steam-content/
├── linux-x64/     # Linux platform content
├── win-x64/       # Windows platform content
└── osx-universal/ # macOS universal binary content

Each directory should contain the complete application files for its corresponding platform.

Preview Mode Usage

Preview mode does not set any branch live, so it is suitable for testing and validation:

if [ "$STEAM_PREVIEW_INPUT" = 'true' ]; then
  cmd+=(--preview)
fi

This lets you upload to Steam first for verification, then switch to the formal branch after everything checks out.

Error Handling and Logging

The scripts include complete error handling and logging:

Validate that the GitHub Release exists.
Check required metadata files.
Ensure platform content is present.
Generate a GitHub Actions summary report.

This information is highly valuable for both debugging and auditing.

Artifact Management

The workflow generates two kinds of artifacts:

portable-steam-release-preparation-{tag}: release preparation metadata
portable-steam-build-metadata-{tag}: Steam build metadata

These artifacts can be used for later auditing and debugging. A retention period of 30 days is a practical default.

Real-world Usage

In the HagiCode project, this automated release workflow has already run successfully across multiple versions. The entire path from GitHub Release to the Steam platform is fully automated and requires no manual intervention.

This significantly improved both release efficiency and reliability. In the past, manually publishing one version took more than 30 minutes. Now the entire process finishes in just a few minutes.

More importantly, the automated workflow reduces the chance of human error. Every release follows the same standardized process, which makes the results more predictable.

Summary

With the approach described in this article, we achieved:

Full automation from GitHub Release to the Steam platform.
Multi-platform Depot uploads.
Secure authentication based on Steam Guard.
Flexible switching between preview mode and formal release.
Complete error handling and logging.

This solution is not only suitable for the HagiCode project, but can also serve as a reference for other projects planning to launch on Steam. If you are also considering Steam release automation, I hope this practical experience is useful to you.

Technology can feel complex or simple depending on the path you choose. The key is finding a workflow that fits your needs.

If this article helped you, feel free to star the HagiCode GitHub repository or visit the official website to learn more.

References

Copyright Notice

Thank you for reading. If you found this article useful, you are welcome to like, bookmark, and share it. This content was created with AI-assisted collaboration, and the final content was reviewed and confirmed by the author.

Author: newbe36524
Original article: https://docs.hagicode.com/blog/2026-04-16-steam-release-automation-github-actions/
Copyright notice: Unless otherwise stated, all articles in this blog are licensed under BY-NC-SA. Please cite the source when reposting.

How to Use GitHub Actions + image-syncer for Automated Image Sync from Docker Hub to Azure ACR

Jan 25, 2026

Automating Image Sync from Docker Hub to Azure ACR

This article explains how to use GitHub Actions and the image-syncer tool to automate image synchronization from Docker Hub to Azure Container Registry, solving the problem of slow Docker Hub access in mainland China and some Azure regions, while improving image availability and deployment efficiency in Azure environments.

Background / Introduction

The HagiCode project uses Docker images as its core runtime components, with the main images hosted on Docker Hub. As the project has evolved and Azure deployment needs have grown, we encountered the following pain points:

Slow image pulls, because access to Docker Hub is limited in mainland China and some Azure regions
Relying on a single image source creates a single point of failure risk
Using Azure Container Registry in Azure environments provides better network performance and integration experience

To solve these problems, we need to establish an automated image synchronization mechanism that regularly syncs images from Docker Hub to Azure ACR, ensuring users get faster image pull speeds and higher availability in Azure environments.

About HagiCode

We are building HagiCode, an AI-driven coding assistant that makes development smarter, more convenient, and more enjoyable.

Smart: AI assistance throughout the entire process, from idea to code, boosting coding efficiency several times over. Convenient: Multi-threaded concurrent operations make full use of resources and keep the development workflow smooth. Fun: Gamification and an achievement system make coding less dull and more rewarding.

The project is evolving rapidly. If you are interested in technical writing, knowledge management, or AI-assisted development, welcome to check it out on GitHub.

Technical Solution Comparison

When defining the solution, we compared multiple technical approaches:

1. image-syncer (final choice)

Incremental sync: only synchronizes changed image layers, significantly reducing network transfer
Resume support: synchronization can resume after network interruptions
Concurrency control: supports configurable concurrency to improve large image sync efficiency
Robust error handling: built-in retry mechanism for failures (3 times by default)
Lightweight deployment: single binary with no dependencies
Multi-registry support: compatible with Docker Hub, Azure ACR, Harbor, and more

2. Docker CLI

No incremental sync support: each run requires pulling the full image content
Lower efficiency: large network transfer volume and longer execution time
Simple and easy to use: relies on familiar docker pull / docker push commands

3. Azure CLI

Higher complexity: requires Azure CLI authentication setup
Functional limitations: az acr import is relatively limited
Native integration: integrates well with Azure services

Architecture Design Decisions

Decision 1: Set the sync frequency to daily at 00:00 UTC

Balances image freshness with resource consumption
Avoids peak business hours and reduces impact on other operations
Docker Hub images are usually updated after daily builds

Decision 2: Sync all image tags

Maintains full consistency with Docker Hub
Provides flexible version choices for users
Simplifies sync logic by avoiding complex tag filtering rules

Decision 3: Store credentials in GitHub Secrets

Natively supported by GitHub Actions with strong security
Simple to configure and easy to manage and maintain
Supports repository-level access control

Risk Assessment and Mitigation

Risk 1: Azure ACR credential leakage

Use GitHub Secrets for encrypted storage
Rotate ACR passwords regularly
Limit ACR account permissions to push-only
Monitor ACR access logs

Risk 2: Sync failures causing image inconsistency

image-syncer includes a built-in incremental sync mechanism
Automatic retry on failure (3 times by default)
Detailed error logs and failure notifications
Resume support

Risk 3: Excessive resource consumption

Incremental sync reduces network transfer
Configurable concurrency (10 in the current setup)
Monitor the number and size of synchronized images
Run synchronization during off-peak hours

Core Solution

We use an automated GitHub Actions + image-syncer solution to synchronize images from Docker Hub to Azure ACR.

Implementation Steps

1. Preparation

Create or confirm an Azure Container Registry in Azure Portal
Create ACR access credentials (username and password)
Confirm access permissions for the Docker Hub image repository

2. Configure GitHub Secrets

Add the following secrets in the GitHub repository settings:

AZURE_ACR_USERNAME: Azure ACR username
AZURE_ACR_PASSWORD: Azure ACR password

3. Create the GitHub Actions workflow

Configure the workflow in .github/workflows/sync-docker-acr.yml:

Scheduled trigger: every day at 00:00 UTC
Manual trigger: supports workflow_dispatch
Extra trigger: run when the publish branch receives a push (for fast synchronization)

4. Workflow execution flow

Sequence	Participant	Action	Description
1	GitHub Actions	Trigger workflow	Triggered by schedule, manual run, or a push to the `publish` branch
2	GitHub Actions → image-syncer	Download and run the sync tool	Enter the actual sync phase
3	image-syncer → Docker Hub	Fetch image manifests and tag list	Read source repository metadata
4	image-syncer → Azure ACR	Fetch existing image information from the target repository	Determine the current target-side state
5	image-syncer	Compare source and target differences	Identify image layers that need to be synchronized
6	image-syncer → Docker Hub	Pull changed image layers	Transfer only the content that needs updating
7	image-syncer → Azure ACR	Push changed image layers	Complete incremental synchronization
8	image-syncer → GitHub Actions	Return synchronization statistics	Includes results, differences, and error information
9	GitHub Actions	Record logs and upload artifacts	Useful for follow-up auditing and troubleshooting

GitHub Actions Workflow Implementation

Here is the actual workflow configuration in use (.github/workflows/sync-docker-acr.yml):

name: Sync Docker Image to Azure ACR

on:
  schedule:
    - cron: "0 0 * * *" # Every day at 00:00 UTC
  workflow_dispatch: # Manual trigger
  push:
    branches: [publish]

permissions:
  contents: read

jobs:
  sync:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Download image-syncer
        run: |
          # Download the image-syncer binary
          wget https://github.com/AliyunContainerService/image-syncer/releases/download/v1.5.5/image-syncer-v1.5.5-linux-amd64.tar.gz
          tar -zxvf image-syncer-v1.5.5-linux-amd64.tar.gz
          chmod +x image-syncer

      - name: Create auth config
        run: |
          # Generate the authentication configuration file (YAML format)
          cat > auth.yaml <<EOF
          hagicode.azurecr.io:
            username: "${{ secrets.AZURE_ACR_USERNAME }}"
            password: "${{ secrets.AZURE_ACR_PASSWORD }}"
          EOF

      - name: Create images config
        run: |
          # Generate the image synchronization configuration file (YAML format)
          cat > images.yaml <<EOF
          docker.io/newbe36524/hagicode: hagicode.azurecr.io/hagicode
          EOF

      - name: Run image-syncer
        run: |
          # Run synchronization (using the newer --auth and --images parameters)
          ./image-syncer --auth=./auth.yaml --images=./images.yaml --proc=10 --retries=3

      - name: Upload logs
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: sync-logs
          path: image-syncer-*.log
          retention-days: 7

Configuration Details

1. Trigger conditions

Scheduled trigger: cron: "0 0 * * *" - runs every day at 00:00 UTC
Manual trigger: workflow_dispatch - allows users to run it manually in the GitHub UI
Push trigger: push: branches: [publish] - triggered when the publish branch receives a push (for fast synchronization)

2. Authentication configuration (`auth.yaml`)

hagicode.azurecr.io:
  username: "${{ secrets.AZURE_ACR_USERNAME }}"
  password: "${{ secrets.AZURE_ACR_PASSWORD }}"

3. Image sync configuration

docker.io/newbe36524/hagicode: hagicode.azurecr.io/hagicode

This configuration means synchronizing all tags from docker.io/newbe36524/hagicode to hagicode.azurecr.io/hagicode

4. image-syncer parameters

--auth=./auth.yaml: path to the authentication configuration file
--images=./images.yaml: path to the image synchronization configuration file
--proc=10: set concurrency to 10
--retries=3: retry failures 3 times

GitHub Secrets Configuration Checklist

Configure the following in Settings → Secrets and variables → Actions in the GitHub repository:

Secret Name	Description	Example Value	How to Get It
AZURE_ACR_USERNAME	Azure ACR username	hagicode	Azure Portal → ACR → Access keys
AZURE_ACR_PASSWORD	Azure ACR password	xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx	Azure Portal → ACR → Access keys → Password

Usage Instructions

1. Manually trigger synchronization

Open the Actions tab of the GitHub repository
Select the Sync Docker Image to Azure ACR workflow
Click the Run workflow button
Choose the branch and click Run workflow to confirm

2. View synchronization logs

Click a specific workflow run record on the Actions page
View the execution logs for each step
Download the sync-logs file from the Artifacts section at the bottom of the page

3. Verify synchronization results

# Log in to Azure ACR
az acr login --name hagicode

# List images and their tags
az acr repository show-tags --name hagicode --repository hagicode --output table

Notes and Best Practices

1. Security recommendations

Rotate Azure ACR passwords regularly (recommended every 90 days)
Use a dedicated ACR service account with push-only permissions
Monitor ACR access logs to detect abnormal access in time
Do not output credentials in logs
Do not commit credentials to the code repository

2. Performance optimization

Adjust the --proc parameter: tune concurrency based on network bandwidth (recommended 5-20)
Monitor synchronization time: if it takes too long, consider reducing concurrency
Clean up logs regularly: set a reasonable retention-days value (7 days in the current setup)

3. Troubleshooting

Issue 1: Authentication failed

Error: failed to authenticate to hagicode.azurecr.io

Solution:

Check whether GitHub Secrets are configured correctly
Verify whether the Azure ACR password has expired
Confirm whether the ACR service account permissions are correct

Issue 2: Network timeout

Error: timeout waiting for response

Solution:

Check network connectivity
Reduce concurrency (--proc parameter)
Wait for the network to recover and trigger the workflow again

Issue 3: Incomplete image synchronization

Warning: some tags failed to sync

Solution:

Check the synchronization logs to identify failed tags
Manually trigger the workflow to synchronize again
Verify that the source image on Docker Hub is working properly

4. Monitoring and alerts

Regularly check the Actions page to confirm workflow run status
Configure GitHub notifications to receive workflow failure alerts promptly
Monitor Azure ACR storage usage
Regularly verify tag consistency

Frequently Asked Questions and Solutions

Q1: How do I sync specific tags instead of all tags?

Modify the images.yaml configuration file:

# Sync only the latest and v1.0 tags
docker.io/newbe36524/hagicode:latest: hagicode.azurecr.io/hagicode:latest
docker.io/newbe36524/hagicode:v1.0: hagicode.azurecr.io/hagicode:v1.0

Q2: How do I sync multiple image repositories?

Add multiple lines in images.yaml:

docker.io/newbe36524/hagicode: hagicode.azurecr.io/hagicode
docker.io/newbe36524/another-image: hagicode.azurecr.io/another-image

Q3: How do I retry after a synchronization failure?

Automatic retry: image-syncer includes a built-in retry mechanism (3 times by default)
Manual retry: click Re-run all jobs on the GitHub Actions page

Q4: How do I view detailed synchronization progress?

View real-time logs on the Actions page
Download the sync-logs artifact to see the full log file
The log file includes the synchronization status and transfer speed for each tag

Q5: How long does synchronization take?

Initial full synchronization: typically takes 10-30 minutes depending on image size
Incremental synchronization: usually 2-5 minutes if image changes are small
Time depends on network bandwidth, image size, and concurrency settings

Suggested Enhancements

1. Add synchronization notifications

Add a notification step to the workflow:

- name: Notify on success
  if: success()
  run: |
    echo "Docker images synced successfully to Azure ACR"

2. Implement image tag filtering

Add tag filtering logic to the workflow:

- name: Filter tags
  run: |
    # Sync only tags that start with v
    echo "docker.io/newbe36524/hagicode:v* : hagicode.azurecr.io/hagicode:v*" > images.yaml

3. Add a synchronization statistics report

- name: Generate report
  if: always()
  run: |
    echo "## Sync Report" >> $GITHUB_STEP_SUMMARY
    echo "- Total tags: $(grep -c 'synced' image-syncer-*.log)" >> $GITHUB_STEP_SUMMARY
    echo "- Sync time: ${{ steps.sync.outputs.duration }}" >> $GITHUB_STEP_SUMMARY

Conclusion

With the method introduced in this article, we successfully implemented automated image synchronization from Docker Hub to Azure ACR. This solution uses the scheduled and manual trigger capabilities of GitHub Actions together with the incremental synchronization and error-handling features of image-syncer to ensure timely and consistent image synchronization.

We also discussed security best practices, performance optimization, troubleshooting, and other related topics to help users better manage and maintain this synchronization mechanism. We hope this article provides valuable reference material for developers who need to deploy Docker images in Azure environments.

References

Reader Interaction

Thank you for reading. If you found this article useful, please click the like button below 👍 so more people can discover it.

AI Assistance Disclosure

This content was created with AI-assisted collaboration, reviewed by me, and reflects my own views and position.

Metadata

Author: newbe36524
Article URL: https://hagicode.com/blog/2026/01/25/how-to-sync-docker-hub-to-azure-acr-with-github
Copyright: Unless otherwise stated, all articles on this blog are licensed under BY-NC-SA. Please include attribution when reprinting.

DevOps

How to Automate Steam Releases with GitHub Actions

Background

About HagiCode

Architecture Design

Workflow Implementation

Trigger Parameter Design

Self-hosted Runner Configuration

Concurrency Control

Core Script Implementation

Preparing Release Inputs

Steam Guard Authentication

VDF Configuration Generation

SteamCMD Invocation

Multi-platform Depot Handling

Release Workflow

Step 1: Prepare the GitHub Release

Step 2: Trigger the Steam Release Workflow

Step 3: Execute the Release Flow Automatically

Configuration Guide

Required Secrets Configuration

Environment Variable Configuration

Best Practices

Steam Guard Authentication Management

Content Directory Structure

Preview Mode Usage

Error Handling and Logging

Artifact Management

Real-world Usage

Summary

References

Copyright Notice

Automating Image Sync from Docker Hub to Azure ACR

Background / Introduction

About HagiCode

Technical Solution Comparison

1. image-syncer (final choice)

2. Docker CLI

3. Azure CLI

Architecture Design Decisions

Decision 1: Set the sync frequency to daily at 00:00 UTC

Decision 2: Sync all image tags

Decision 3: Store credentials in GitHub Secrets

Risk Assessment and Mitigation

Risk 1: Azure ACR credential leakage

Risk 2: Sync failures causing image inconsistency

Risk 3: Excessive resource consumption

Core Solution

Implementation Steps

1. Preparation

2. Configure GitHub Secrets

3. Create the GitHub Actions workflow

4. Workflow execution flow

GitHub Actions Workflow Implementation

Configuration Details

1. Trigger conditions

2. Authentication configuration (auth.yaml)

3. Image sync configuration

4. image-syncer parameters

GitHub Secrets Configuration Checklist

Usage Instructions

1. Manually trigger synchronization

2. View synchronization logs

3. Verify synchronization results

Notes and Best Practices

1. Security recommendations

2. Performance optimization

3. Troubleshooting

Issue 1: Authentication failed

Issue 2: Network timeout

Issue 3: Incomplete image synchronization

4. Monitoring and alerts

Frequently Asked Questions and Solutions

Q1: How do I sync specific tags instead of all tags?

Q2: How do I sync multiple image repositories?

Q3: How do I retry after a synchronization failure?

Q4: How do I view detailed synchronization progress?

Q5: How long does synchronization take?

Suggested Enhancements

1. Add synchronization notifications

2. Authentication configuration (`auth.yaml`)