Push Docker Images to Container Registry (Pseudocode Edition)

Introduction

As part of my DevOps workflows, I regularly build and push Docker images to container registries for deployment into different environments. These pipelines are typically written in YAML, which works, but let’s be honest, it’s not always readable or beginner-friendly.

So I’m starting a series where I convert my CI/CD workflows into pseudocode. This lets me and others focus on what the workflow does, not just the syntax it uses. Think of this as documentation for humans.

---

Why I’m Sharing Pseudocode Versions

Over the years, I’ve noticed how easy it is to lose sight of the intent behind automation:

• You inherit pipelines with no explanation.
• You tweak things without fully understanding them.
• You avoid touching workflows because you’re afraid of breaking them.

Sound familiar?

Writing pseudocode helps me:

• Understand and explain complex workflows faster
• Share knowledge with colleagues who aren’t YAML-fluent
• Think more clearly about the architecture of automation
• Decouple the logic from the implementation

By stripping out vendor names and focusing purely on the process, these writeups should help anyone using containers and CI/CD, no matter your platform.

---

The Workflow: Pushing Docker Images to a Registry

This workflow supports pushing Docker images to either a non-production or production container registry, based on user input.

Trigger

On manual trigger (via UI or API):
  Accept these optional inputs:
    - deploy_to_nonprod: boolean
    - deploy_to_prod: boolean
    - image_tags: JSON string or file path (maps image names to tags)
    - custom_repo: optional string to override default repo name

---

Job 1: Push to Production Registry

Condition: Runs only if deploy_to_prod is true.

Set environment variables:
  - REGION
  - PROD_ACCOUNT_ID
  - PROD_REGISTRY_URI

Steps:
1. Checkout source code
2. Assume cloud role using OIDC (for access to production)
3. Retrieve external Docker registry credentials from parameter store
4. Login to Docker registry
5. Login to production container registry
6. Load image_tags input:
    - Use inline JSON or file path
    - Validate it is proper JSON
7. For each image in image_tags:
    - Determine source and target image paths
    - Pull image from source
    - Tag it with the target registry URI
    - Push it to the production registry

---

Job 2: Push to Non-Production Registry

Condition:
Runs if:

• deploy_to_nonprod is true, OR
• image_tags is provided and deploy_to_prod is false.

Set environment variables:
  - REGION
  - NONPROD_ACCOUNT_ID
  - NONPROD_REGISTRY_URI

Steps:
1. Checkout source code
2. Assume cloud role using OIDC (for access to nonprod)
3. Retrieve external Docker registry credentials from parameter store
4. Login to Docker registry
5. Login to nonprod container registry
6. Load image_tags input:
    - Use inline JSON or file path
    - Validate it is proper JSON
7. For each image in image_tags:
    - Determine source and target image paths
    - Pull image from source
    - Tag it with the target registry URI
    - Push it to the nonprod registry

---

Image Mapping Logic

For each image tag key:
  If key matches known alias:
    Map to correct source and target paths
  Else:
    Use the key as both source and target image names

---

Wrap-Up

This workflow is part of a modular pipeline system that allows us to promote images across environments using flexible inputs and secure credential handling.

I hope this breakdown helps you understand not just how a workflow is written, but why it’s structured the way it is. If you want to contribute improvements or need help translating your own workflows into pseudocode, drop me a message or comment below.

---