Coder Legion - Recent posts tagged githubactions

Dynamic GitHub Actions Dropdowns — A Clever Workaround Made Reusable!

Fri, 16 Oct 2026 19:57:00 +0000

GitHub Actions doesn't natively support dynamically populated dropdown options for workflow_dispatch inputs. This can become a maintenance headache, especially when managing multiple packages in an npm monorepo.

I came across a clever workaround shared by @jeevan-vj, demonstrating how to dynamically maintain dropdown options by automatically updating GitHub Actions workflow YAML files.

Inspired by that approach, I built a reusable GitHub Actions workflow that uses a dedicated WORKFLOW_TOKEN to update workflow files and automatically discover publishable packages in an npm monorepo.

Here's what my implementation adds:

✅ Automatic package discovery — Detects publishable npm workspace packages without maintaining a hardcoded list.

✅ Multi-workflow synchronization — Keeps package dropdown options consistent across multiple GitHub Actions workflows.

✅ YAML formatting preservation — Uses Python and ruamel.yaml to update workflow configurations while preserving their structure and formatting.

✅ Automatic and manual execution — Supports synchronization on push as well as manual triggering when needed.

✅ Configurable token authentication — Accepts a workflow-token secret, allowing each consuming repository to choose its own secret name.

✅ No unnecessary commits — Updates workflow files only when package options actually change.

The end result?

My release, publish, restore, reset, and release-draft workflows now automatically stay synchronized with the publishable packages in my npm monorepo.

No more manually updating package dropdowns every time a package is added, renamed, or removed.

Even better, the solution is reusable across repositories, so I have adopted the same automation in other repos without duplicating the synchronization logic.

Original inspiration — @jeevan-vj:
https://github.com/jeevan-vj/iamjeevan/blob/master/data/blog/dynamically-populating-parameter-options-in-manual-github-action.md

My reusable workflow implementation:
https://github.com/moyarich/reusable-workflows/blob/main/.github/workflows/reusable_sync-release-package-choices.yml

Real-world implementation — Workspace Tools:
https://github.com/moyarich/workspace-tools/blob/main/.github/workflows/sync-release-package-choices.yml

Huge credit to @jeevan-vj for sharing the original workaround. It's a great example of how an open-source idea can evolve into a reusable solution that benefits other developers.

How are you managing dynamic inputs in your GitHub Actions workflows? Have you found another approach?

My First Project: From a Local Folder to GitHub Using Git and SSH

Thu, 08 Oct 2026 04:21:17 +0000

My First Project: From a Local Folder to Git hub Using Git and SSH

GIT

Introduction

Git is an open source version control system used to manage projects. It is fast and efficient to manage projects using git. You can easily track the project version, history, modifications, and many more project activities. It allows for ease of collaboration while working on projects as teams.

Installing Git

Download and install git from Git. Ensure you download for your respective operating system.

Configuring Git

Before using Git effectively, you have to configure your identity by setting up your username and email.

This allows to easily track any changes to your project and the associate, that is; who made the changes?

To set up your identity, follow the following steps, using Git Bash a git terminal:

Steps

To set your username

git config --global user.name "YOUR NAME"

In place of YOUR NAME type in your correct user name that will be associated with your github account activity.

To set your email

git config --global user.email "youemail@example.com"

Note: It is recommended to use your correct email that is associated with your GitHub account.

Rename you GitHub branch to main

git config --global init.Branch main

After setting up your identity you can verify your configurations to confirm your identity for each field set.

To check your:

User name

`git config --global user.name`

`git config --global user.email`

Branch

git config --global init.Branch`

You can use the following command to check all you account details instead:

`git config --global --lists`

SSH

SSH key is a secure credential used to authentication to accessing network resources confidentially without need of a password. The ssh-key contains two keys. A Public and Private key.

Public key is used publicly, that is it is shared between peers. Used to identify you remote resources.

Private key it is a pair key that is kept as a secret for identifying your local machine.

Generating an SSH Key

Using Git Bash

Before generating a new SSH Key, it is recommended to check and confirm if you have an existing key which you can use.

To check if you have an existing key use the following command:

`ls -al ~/.ssh`

The command will list all existing ssh keys. Here sample output:

If there is no existing key, you can generate a new key that you will use to link your computer with your github account.

To generate a new ssh key, follow the following steps:

Genereate a new ssh-key

ssh-keygen -t ed25529 -C "youremail@example.com"

The email should be the one associated with with your github account.

Follow the prompt by adding the name of your key, and also you can add the passphrase which is optional.

The passhrase should be memorable, you will need to use it each time you want to access you github account.

Add your key to the SSH-Agent.

Open your Powershell Terminal and follow the steps below:

- Run the following command to start your SSH Agent

	`Get-Service -Name ssh-agent | Set-Service StartupType Manual`

- Add your key to the  path using the  command

	`ssh-add <PATH/TO/YOUR/PRIVATE_KEY>`

After the command, you should specifify the path to your private key and add it to your host machine's ssh-agent. i.e. ssh-add "C:/Users/<YOUR_USER_NAME/.ssh/<YOUR_PRIVATE_KEY>

If you don't know your computer's user name, you can use the whoami command to see your username.

Your _PRIVATE_KEYNAME is the name that you gave to your key.

- Once you're done, close your Powershell terminal and return to Git Bash.

- Type the following command

	`git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe`

- Then Clip and copy your key using the following commands:

	`clip < ~/.ssh/<PUBLIC_KEY.pub>`

i.e clip < /.ssh/my_key.pub

	`cat ~/.ssh/<PUBLIC_KEY.pub>`

i.e. 'cat ~/.ssh/my_key.pub` to view your public ssh key

- After displaying your key, select and copy the key to add to your GitHub account.

Adding Your Key to GitHub

To connect your computer and git-hub is necessary to facilitate access to your remote resources from your local computer.

You need to add your SSH Keys to GitHub to facilitate the connection. To achieve this, follow the steps:

If you have an existing GitHub account:

a. Login to your account using your email/username and password.

b. From the profile section, go to Settings

c. Scroll to SSH and GPG Key. Navigate and click on New SSH Key on the SSH Key Section to your right.

e. Add the Title/Name of the key i.e. Ubuntu Laptop, the key will be used for Authentication

f. Paste your key to the available textbox.

g. Finally, click on Add Key to save your key. You'll be prompted to re-enter your git-hub account password (login password), to confirm your authenticity before saving.

Now you are ready to go. Before you start, it is good you test your connection to check if it was successful.

Run Powershell as an Administrator and use the following command to test connection:

`ssh -T git@github.com`

If the connection is successful, your username will be displayed along with a success message.

If successful, you are good to go and work on your project.

Working With Folders

To keep you project structural and more organized; you've to keep its files and scripts in folders.

This will make it easier to navigate and access the project. Follow the steps below to work with folders in Windows.

In Git Bash Terminal(Opened normally)

To navigate and change location use the following command
```
`cd <path_location>`
```

To select the current location

	`cd .`

To get to the previous location one step back use

	`cd ..`

Getting back to the root directory use

	`cd ~`

You can also move to a specific folder by specifying the path to that folder

	`cd <path/to/folder>

example: cd "C:/Users/Admin/Desktop/My-Project"

My-Project/ is a folder located in Desktop, which is for the user with the username Admin.

To create a directory or folder use
```
`mkdir <directory_name>`
```

i.e. Create a directory named My-First-Project in Desktop mkdir My-First-Project

Navigate to your created folder. Assuming you are on Desktop, use the following command:
```
`cd My-First-Project/`
```

So your bash terminal path will look like ~/Desktop/My-First-Project

To list and view items use the following command
```
`ls`
```

It will list all files and folders excluding the hidden files and folders. As shown below:

To list and view all files and folders including the hidden ones you add -a attribute to the ls command as below

	`ls -a`

To list files and display their attributes we add the -l attribute to the ls command.

	`ls -l`

Note: You can combine the attributes to list all files and their attributes i.e. as ls -al

You can delete an empty folder using
```
`rm -r <folder_name>`
```

To delete a folder together with its contents we use the rm -r <non-empty_folder_name> command.

Example: Create a folder in you my project folder using the mkdir command, inspect the folder created and its contents, then delete the folder using the rm command:

Steps

Create scripts: mkdir scripts
Navigate to scripts and back to your project folder: cd scripts/ and cd ..
Inspect scripts: ls scripts/
Delete scripts: rm -r scripts/

Note: rm without any attribute will no delete a directory/folder even if empty, the attribute -r tells the command rm that what you're deleting is a directory.

You can copy and paste contents between different folders.

To copy contents moves a duplicate of the files to another location leaving the original intact.

While using the cp command you have to specify the file/contents path and the destination address. Example:

To copy some file named hello.txt to the scripts folder; you need to recreate the folder and create the file in the root directory then copy it to scripts folder in your projects folder

Steps

In your project folder create scripts mkdir scripts
Navigate to your project root folder and create the file hello.txt touch hello.txt
Copy the file to scripts cp hello.txt ~/scripts
Inspect both locations to see that the file exists in both location. ls and ls scripts

Note: You can specify the file path in the cp command if the file is in a different location and the destination path address

i.e. cp <~/path/to/file_to_be_copied.txt> <~/path/to_destination/>

You can move a file or any content completely from the source to an new destination using the mv command.

Example: Move hello.txt file from the project's folder to a new folder named docs

`mv hello.txt docs/

Note: You can also specify the file path in case the files and destination address are in different locations i.e. mv <~/path/from_source/hello.txt> <~/path/to_destination_folder/>

Working With Files

While working in your project you will need to create different files for your project.

The different files will be saved in different directories depending on their type and use.

The organization will help us to achieve a proper project structure, easier to navigate and access our project files.

We will create our files using Git Bash terminal.

To create a file we'll use the touch command.

Create a file named hello-world.txt in your project root directory.

	`touch hello-world.txt`

Use the ls command to confirm your file has been created.
To view the contents of the file we use the cat command, since our file is empty it will display 'nothing'.
```
`cat hello-world.txt`
```
To add contents to our file we use the echo command.

Add the following text to the file hello-world.txt; "Hello, World"

	`echo "Hello, World!" > hello-world.txt`

We use the > to redirect the output to our file. > Rewrites any content in the file.

If you want to add more content to the file use >>, more text will be added to our file.

Example; add the following text to our file "I am happy to learn SSH and Git".

	`echo "I am happy to learn Git and SSH" >> hello-world.txt`

cat hello-world.txt to view the contents of the file.

Editing you file using nano

Nano is an inbuilt text editor in Git Bash.

It helps us to navigate through our files; scripts, text file, .... once we make mistakes.

To open our script or text file we use the nano command in git bash then specify the file we want to open, for example open hello-world.txt using nano:

	`nano hello-world.txt'

There are many more commands for nano that will help you edit your text file. For example the most common commands are:

1. Ctr + O - To save your file

2. Ctrl + X - To exit your nano text editor

3. Ctrl + K - To Cut text in the editor

4. Ctrl + U - To Paste your text

5. Ctrl + G - To find help for you nano editor.

There are many more commands of help that you can use to edit you files in nano editor.

Your First Project

Initialize your first project with git

Before running the command, check to confirm that you are in your project folder using the pwd command.

The pwd command means print working directory it shows your current location with regard to the root directory.

If in your project directory, the path will end with the name of the project folder. I.e. My-First-Project

Use the git init command.

The command is used to initialize our project directory as a git repository.

Git repository structure.

After running the above command, you may notice notification of git initializing an empty git repo...

If you list to view the structure using the ls command you may notice a .git/ folder.

The folder contains Git's internal repository information, which git uses to manage activities such as: push, commits, pull, Branches, project history, repository configurations,....

Checking the project status

	`git status`

Used to show what's happening with your project currently.

It can show things such as untracked files, staged files to be committed yet, if the working tree is clean meaning everything has been committed.

The above show that there is nothing that has been staged for commit, there are three untracked files in the initialized repository.

Staging your project files

	`git add .`

It adds your project files to git for tracking.

Checking on the status of the staged file, you should get such an output with git status command

It prepares all you changes for the next commit.

You can stage a single file by specifying the file/folder you want to stage i.e. git add <file_name.txt>.

You should see almost a similar output when using git status command after staging a single file

Using the . means you stage everything in your project folder.

Commiting you staged files

	`git commit -m "<commit message>"`

Creates a saved checkpoint.

The message should be precise and clear, related to the activity carried out. i.e. "My First Project Using Git Commit"

It does not upload anything to git-hub yet.

Uploading to git-hub

	`git push -u origin <branch_name>

Sends all the committed changes to GitHub. However, in our case we get the above error because we have not linked our local project repo to a git-hub remote repository.

We will be linking our repositories in the next section.

After running this command, you can easily check on the changes whether they reflect on GitHub via your browser.

However, for us we are yet to see these changes. This may not work since we are yet to create a remote repository which we will then connect to our local project in our laptop.

Creating a remote repository

To create a remote repository, follow the following steps:

Login to your git-hub account
In your account click on "Create New Repository"
Enter the name of your Repository as "My-First-Project"
Do not create a README, uncheck the checkbox
Provide a brief descriptions for your project. The description is: "My First Project: From a Local Folder to Git hub Using Git and SSH"
Then click on Create Repository

A new empty repository is created with the name "My-First-Project"

Navigate to your repository
Click on the code section, then click on ssh tab and copy the ssh code

We'll use the ssh code to connect our remote and local repositories before pushing our project.

Connecting our local and remote repositories

Navigate to your git initialized project folder

Type in the following command and thereafter paste the ssh code for your remote repository and hit enter.

	`git remote add origin <your_remote_ssh_code>`

i.e. git remote add origin git@github.com:MakoriNyachaki/My-First-Github-Project.git

Rename your branch

If your remote repository's branch is not main rename it to main

	`git branch -m main`

Check the remote

	`git remote -v`

Push your project to git-hub

	`git push -u origin <branch_name>`

i.e. git push -u origin main this works to upload our committed changes to our git-hub repository.

Summary

An introductory article for learning GIT and SSH. It is thrilling practical exercise for generating ssh keys, working with folders and files, connecting local project folders with remote repositories, and working with git. The introductory article requires one to do further research on so many commands that are available for the different tools we have used here in order to be an expert. Let's learn forward.

AURA v0.1.0: Deterministic Trigger Extraction, Auditable Math & a Self-Healing Analytics Engine

Sat, 26 Sep 2026 15:51:09 +0000

If you follow AI safety, you know the uncomfortable truth: modern LLM guardrails are failing not because of complex zero-day exploits, but because of sloppy heuristics, brittle filters, and naive prompt-matching.

We built AURA to be pragmatic: deterministic, testable, fully auditable, and completely immune to the hallucination of its own telemetry.

Today, we’re unpacking AURA v0.1.0 — explaining our architectural decisions, showing real code excerpts, diving into non-linear risk scoring math, and solving the silent problem of lost repository analytics on GitHub.

1. System Architecture at a Glance

Data flow in AURA is intentionally simple, pipeline-driven, and fully reproducible:

Source Cases (public_cases/*.json) → Cleaned, validated, and normalized via scripts/normalize-percases.ts
Rule Extraction (scripts/extract-triggers.ts) → Contextual regex and sliding-window token analysis.
Weights & Signal Mapping → Derived from config/signal-mapping.json and saved to config/trigger-weights.json.
Scoring & Policy Enforcement (scripts/recalc_confidence.ts) → Non-linear math transform + cross-check audit logic via scripts/policy/crossCheckAdapter.ts.
Persisted Telemetry → Automated daily snapshots written to analytics/traffic-history.json via GitHub Actions.

2. Non-Linear Risk Normalization: Why We Don't Just "Sum Things Up"

We compute a transparent raw evidence sum (confidence_raw) and convert it into a bounded score via a diminishing‑returns exponential:

\[ \text{confidence} = 1 - e^{-\alpha \cdot \text{confidence\_raw}} \]

This keeps scores in [0...1] and avoids noisy amplification from many weak cues. Implementation (excerpt from scripts/recalc_confidence.ts):

// computedRaw is the honest sum of trigger weights + cross-check contributions
const alpha = (typeof cfg.normAlpha === 'number') ? cfg.normAlpha : 1.0;
const normalized = 1 - Math.exp(-alpha * computedRaw);
let newVal = Math.round(normalized * 100) / 100;
if (newVal < minFloor) newVal = minFloor;
e.confidence_raw = Math.round(computedRaw * 100) / 100;
e.confidence = newVal;

Tuning Sensitivity (${\alpha}$)

Lower $\alpha$ (0.1 - 0.2): Conservative normalization; requires heavier evidence to push confidence towards 1.0.
Higher ${\alpha}$ (0.5+): Aggressive sensitivity for high-security environments.
AURA Baseline ($\alpha = 0.3$): Striking a balance where $\text{confidence\_raw} = 3.0$ yields $\approx 0.59$, requiring compounding signals for a hard policy block.

3. Hardening Trigger Extraction: Sliding Windows & Contextual Anchors

Keyword lists are a recipe for false positives. Matching a naive string like "generate 500" catches harmless test cases alongside malicious payloads.

To balance precision and recall, AURA v0.1.0 introduces ordered-within-window token matching.

Sliding Window Engine

Excerpt from scripts/extract-triggers.ts showing how AURA tolerates small syntactic noise without matching scattered words across an entire prompt:

function containsOrderedWithinWindow(haystack: string[], needle: string[], window = 5): boolean {
  if (needle.length === 0) return false;
  if (needle.length === 1) return haystack.indexOf(needle[0]) !== -1;
  for (let i = 0; i < haystack.length; i++) {
    if (haystack[i] !== needle[0]) continue;
    let idx = i + 1;
    let matched = 1;
    for (let k = 1; k < needle.length && idx < Math.min(haystack.length, i + window + 1); idx++) {
      if (haystack[idx] === needle[k]) { matched++; k++; }
    }
    if (matched === needle.length) return true;
  }
  return false;
}

Contextual Anchors vs. Co-Occurrence Cues

In config/trigger-extraction.json, bulk asset creation explicitly requires a deception target:

{
  "trigger": "non-consensual pattern generation",
  "pattern": "\\bgenerate\\s+\\d+\\s+(?:deceptive\\s+assets|phishing\\s+emails|fake\\s+documents|fake\\s+profiles|fake\\s+accounts|malicious\\s+payloads|spam\\s+emails|synthetic\\s+attacks)\\b",
  "description": "Bulk-generation demand with deception-specific targets."
}

For generic terms like "audit", we mandate multi-token co-occurrence:

{
  "trigger": "unauthorized audit camouflage",
  "cues": ["audit", "unauthorized", "independent", "bypass", "without permission"],
  "description": "Require co-occurrence of 'audit' with authorization‑bypass phrasing."
}

I don't know about you, but I got tired of seeing my project's growth through the lens of GitHub’s default 14-day window. GitHub silently wipes daily clone and view metrics after two weeks, leaving open-source maintainers completely blind to long-term adoption trends unless they buy third-party analytics dashboards.

To solve this, AURA v0.1.0 includes an automated, self-healing snapshot pipeline in .github/workflows/traffic-history.yml.

How the Analytics Snapshot Pipeline Works:

Daily Ingestion: Executes a daily cron job via GitHub REST API.
Deduplication: Merges metrics into analytics/traffic-history.json while purging duplicate artifacts.
Self-Healing Merge Logic: If concurrent workflow updates cause a direct git push to main to fail, the action politely opens a temporary PR, squash-merges it via actions/github-script, and cleans up after itself:

- name: Auto-merge PR and delete branch
  uses: actions/github-script@v6
  with:
    github-token: ${{ secrets.TRAFFIC_TOKEN }}
    script: |
      const head = `auto/traffic-report-${process.env.GITHUB_RUN_ID}`;
      const { data: prs } = await github.rest.pulls.list({ owner: context.repo.owner, repo: context.repo.repo, head: `${context.repo.owner}:${head}`, state: 'open' });
      if (prs && prs.length > 0) {
        await github.rest.pulls.merge({ owner: context.repo.owner, repo: context.repo.repo, pull_number: prs[0].number, merge_method: 'squash' });
        await github.rest.git.deleteRef({ owner: context.repo.owner, repo: context.repo.repo, ref: `heads/${head}` });
      }

5. Community Spotlight: Catching a Subtle Async Race Condition

One of the best parts of open-sourcing AURA is having sharp contributors look at the edge cases. Our contributor Amirhossein Agrest spotted a subtle async race condition in how case state is updated before disk serialization.

updateCase() awaits cross-check evaluation internally. However, in certain batch execution flows, calling scripts invoked it across collections without awaiting the return promise before writing JSON files to disk.

The result? CLI logs proudly claimed success, while disk artifacts still contained pre-audit state.

// ❌ Potential Race: Fire-and-forget async invocation
for (const entry of entries) updateCase(entry);

// ✅ Fix Pattern: Await all async mutations before serializing to disk
const promises = entries.map(entry => updateCase(entry));
await Promise.all(promises);

We’ve logged this issue (shoutout to Amirhossein!) and are pairing it with artificial network-delay adapters in our test suite to guarantee filesystem persistence never outruns in-memory state in the upcoming patch.

6. Roadmap (What Realistically Comes Next)

v0.2: Programmatic prompt tokenization + TF‑IDF experiments for ranking weak cues (automated test-corpus generation).
Tooling UI: Better cross-trigger clustering and a visual rule editor — because manually squinting at hundreds of lines of raw JSON is a fast track to eye bleed, and my laziness is a major driver for automation.
ML Augmentation: Replace some heuristics with small supervised models for cue disambiguation — but only where deterministic rules fall short (no ML for the sake of ML).

Closing Notes

AURA is not magic, and it doesn't pretend to be. It's a pragmatic stack: deterministic rules, auditable math, and CI that refuses to forget its history.

If you're looking for a silver bullet, good luck! But if you want a system that is testable, inspectable, and built on sound software engineering principles, welcome aboard.

⭐ Check out the repository, inspect the code, and give us a star:
👉 GitHub: kate8382/AURA

Open an issue, or even better — submit a PR with a failing unit test to help us catch edge cases faster.

Demystifying the Ghost Failure in Firebase Hosting GitHub Actions

Thu, 02 Jul 2026 05:48:04 +0000

Imagine your pipeline throwing a red error badge, yet your production application reflects fresh updates perfectly. This exact scenario confuses countless developers utilizing the official Firebase Extended GitHub Action. The workflow crashes with a cryptic warning message stating that the supplied version is the current active version, casting doubt on your continuous deployment pipeline reliability.

Redundant Release Triggers:

The pipeline triggers file hashing and bundles content assets accurately, uploading them to Firebase storage infrastructure seamlessly.
Idempotent State Conflicts: When consecutive builds contain zero file modifications, Firebase optimization logic flags the release bundle as structurally identical to the live production build.
Aggressive Exit Code Flags: The deployment utility interprets this identical state as an operational failure, returning a non-zero exit status that forcefully breaks your workflow chain.

🛠️ The Modern Implementation Strategy:

Conditional Deployment Guards: Introduce a dynamic file change detection mechanism directly inside your continuous integration step definitions.
Idempotent Workflow Controls: Implement custom workflow scripts leveraging the core Firebase CLI directly instead of using abstract, rigid pre-built actions.
Graceful Exit Optimization: Append standard bash execution overrides to capture identical version notices and rewrite exit statuses cleanly to neutral status levels.

🔗 visit our official site: www.nextbigcreative.com

Lazy SRE's guide to secure systems, part 2: the actions you didn't pin

Sun, 07 Jun 2026 21:55:44 +0000

Originally published at harshit.cloud on 2026-04-12.

Last March, someone with write access to the trivy-action repo rewrote 76 of its 77 version tags in place. The tags still resolved to aquasecurity/trivy-action — they just resolved to different commits than they did the week before. Every pipeline that ran aquasecurity/trivy-action@0.20.0 (and every other tagged version) ran the attacker's commit instead. Secrets exfiltrated. The stolen credentials chained into PyPI and took down LiteLLM. Nobody noticed for hours, because the workflow file diff was still clean.

This is part 2. Part 1 covered npm: the dependencies you didn't read. Part 2 is the same problem one level up: the workflows you didn't pin. Part 3 is the unsexy list — Tailscale, PrivateLink, IAP, the PAT you forgot.

The thesis from Part 1 stands. The best security work for a small team is the work Future You at 3am will actually execute. The configuration that makes the wrong thing impossible beats the runbook that only discourages it. With GitHub Actions, "the wrong thing" has gotten very specific over the last twelve months, and the configs to block each variety have gotten correspondingly precise.

pinning is necessary but not sufficient

The first thing the trivy-action incident proves: hash-pinning to @0.20.0 is not pinning. It's a name lookup. The owner of the repo is allowed to rewrite that name. The pin you actually wanted was:

- uses: aquasecurity/trivy-action@9b9a3f5c8a5c7e1b6e4d2f1c9b8a7e6d5c4b3a2f # v0.20.0

Full forty-character SHA. Immutable. The version comment is so the next reader knows what they're looking at; the SHA is so the workflow runs the code you reviewed.

Two GitHub features shipped in 2025 that change the math:

SHA pinning enforcement (Aug 2025). An org-level policy that fails workflow runs using unpinned actions, instead of warning about them. Settings → Actions → General → Action pinning. Turn it on. There is no "we'll get to it" version of this toggle.
Immutable Releases (Oct 2025, GA). Action authors opt in to making release tags non-rewritable after publication. If you publish actions, turn this on for downstream consumers. If you consume actions, prefer ones that have.

The lazy stance: enforcement at the org level. The workflow that doesn't have a forty-character SHA fails the run. The PR can't merge. The work of remembering to pin moves from every engineer's head to one setting.

What this doesn't catch: an attacker who compromises the maintainer account and ships a new tag at a new SHA. The SHA is real. Pinning by SHA doesn't help, because the workflow author will rev to the new version when they read the maintainer's release notes. Which is the next config.

cooldown is the same trick that worked for npm

Part 1's load-bearing config was SAFE_CHAIN_MINIMUM_PACKAGE_AGE_HOURS=48. The principle: most published malware is detected and pulled within hours. If you can wait, the wait does the work for you.

The action ecosystem has the same property, with a longer window. yossarian's analysis puts the cooldown that catches most supply-chain attacks at 7-14 days. So:

pinact --min-age 7 .github/workflows/*.yml

Refuses to write a pin younger than seven days. Add to pre-commit, your CI lint, or whatever your dependabot equivalent runs before opening the bump PR.

For Renovate users, the equivalent lives in the action manager:

{
  "packageRules": [
    { "matchManagers": ["github-actions"], "minimumReleaseAge": "7 days" }
  ]
}

That's it. Same trick, different ecosystem.

Fig. 2 — the wait is doing the work. Seven days closes most of the door; fourteen closes most of the rest.

The empirical question is whether seven days is enough. The trivy-action force-push was detected at about nine — seven would have caught most consumers, not all of them. The cost of fourteen is "your action versions lag upstream by two weeks." If your action surface is small (most teams are running actions/checkout, actions/setup-node, one cloud-login action, maybe a deploy action), set fourteen and forget.

pull_request_target is the new postinstall

Part 1 named postinstall as the single trigger that does the most damage and the single switch (ignore-scripts=true) that closes the most doors. Actions has the same shape and the same fix.

pull_request_target runs in the context of the base repository, with access to repository secrets, but is triggered by a PR from a fork. The legitimate use case is small: comment on PRs, label them, run lightweight metadata jobs. The illegitimate use case is enormous: check out the fork's code and execute it. The attack writes itself. Open a fork, modify a script the trusted workflow runs, watch the runner exfiltrate every secret in the env.

Astral, who maintain uv and ruff, wrote it cleanly: "these triggers are almost impossible to use securely." GitHub partially mitigated this in November 2025 by forcing pull_request_target to always use the default branch's version of the workflow, so an attacker can't push a vulnerable workflow on a feature branch and trigger it. But the foot-cannon still ships loaded if your default-branch workflow checks out PR-head code.

Fig. 3 — same workflow, different trigger, opposite blast radius.

The lazy stance:

Don't use pull_request_target unless you've named the specific reason and one other person has signed off.
If you do, never actions/checkout the PR head from inside it. Check out the base SHA, do the metadata thing, exit.
For everything else, use pull_request. It runs without secrets. Attacker-controlled code stays attacker-jailed.

Same shape as ignore-scripts=true. The setting that closes the class.

the safe defaults that go in every workflow

The four-line workflow header that does the most work per character:

permissions:
  contents: read

defaults:
  run:
    shell: bash -euo pipefail {0}

contents: read overrides the org-level default. If a step needs to push a tag or open a PR, that job opts back up to contents: write explicitly. The default is the safe one.

At the checkout step:

- uses: actions/checkout@<sha> # v4.2.0
  with:
    persist-credentials: false

The default behavior of actions/checkout is to leave a credential sitting in .git/config for the rest of the workflow. Later steps have shipped this credential into uploaded artifacts more than once. Opt out unless a later step in the same job needs to push.

Three secret-access rules with the same flavor:

Step-scoped env:, never workflow-scoped, for any secret.
Never ${{ toJson(secrets) }}. Exposes every secret in the project to the runner. There is no use case.
Never secrets: inherit on reusable workflows. Pass each secret by name. The reusable workflow gets exactly what it asked for.

The trivy-action exfiltration worked partly because secrets were workflow-scoped. The malicious step inherited every credential in the env, not just the one the legitimate scan needed. Step-scoping wouldn't have prevented the credential theft — but it would have bounded the blast radius to one secret instead of all of them.

OIDC, the promise from part 1

Part 1 ended on "the next-tier defenses are real, Part 3 names them." OIDC is the part of that conversation that lives here.

The trade: instead of storing an AWS_ACCESS_KEY_ID in repo secrets and praying nobody exfiltrates it, you configure AWS to trust GitHub's OIDC issuer for a specific repo, branch, and workflow. GitHub mints a short-lived (five-minute) OIDC identity token for the workflow run. The workflow trades that for STS credentials whose lifetime you set (default one hour). Nothing long-lived ever sits in the env.

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@<sha> # v4.0.2
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-deploy
          aws-region: us-east-1
      - run: aws s3 sync ./dist s3://my-bucket

The role's trust policy restricts the OIDC subject to your exact repo and (ideally) branch. An attacker who compromises a fork PR can't assume the role, because they don't match the trust condition. The OIDC JWT itself lasts five minutes and the STS credential is scoped to whatever you configure (default one hour). Even an exfiltrated credential gets the attacker a bounded window of scoped access, not a permanent IAM user.

For Google Cloud, the equivalent is Workload Identity Federation. For HashiCorp Vault, the JWT auth backend. Same shape across providers.

The labor here is genuinely one-time. Configure the trust relationship once per repo, delete the long-lived key, forget about rotation forever. The rotation runbook you're not maintaining is one of the better quiet wins in this post.

zizmor is the local proxy for workflows

Part 1's safe-chain sat in front of every package install and refused malware before bytes hit disk. The action ecosystem's equivalent is zizmor — a workflow linter that reads your YAML and catches the patterns this post is about, before they merge.

brew install zizmor
zizmor .github/workflows/

It catches unpinned actions, pull_request_target with PR-head checkouts, template-injection patterns where attacker-controlled input lands in a run: string, jobs with excessive permissions. Add it to pre-commit:

# .pre-commit-config.yaml
- repo: https://github.com/woodruffw/zizmor-pre-commit
  rev: v1.x  # pin the rev, obviously
  hooks:
    - id: zizmor

The principle is identical to safe-chain. Move the security check from "after the incident, in the postmortem" to "before the PR can merge, on the dev machine." The CI run is the second line of defense. The pre-commit is the first.

the receipts

The above stack is approximately one afternoon: org-level SHA pinning enforcement, pinact --min-age 7 or Renovate minimumReleaseAge: 7 days, the four-line workflow header, persist-credentials: false, no pull_request_target with PR-head checkouts, OIDC for every cloud credential, zizmor in pre-commit.

It will not catch a maintainer-account compromise that ships clean-looking code which activates weeks later. It will not catch a determined attacker who studies your build and writes a payload that survives every linter and looks innocent at PR review. Nothing in this post will. Part 3 will name the controls that buy partial mitigation against that class: sigstore, npm provenance, reproducible builds, attested deployments. And the ones that exist to make the postmortem readable, not to prevent the incident.

For a small team, the delta from this post is moving from "we're one tag-rewrite away from a credential theft cascade" to "an attacker would need a credentialed insider, or a fifteen-minute window of luck against a scoped IAM role." That's the only delta that matters at this scale.

If you do one thing this week, turn on SHA pinning enforcement at the org level. Everything else gates off that.

The Comforting Lie Of SHA Pinning

Wed, 13 May 2026 09:19:41 +0000

Originally published at https://www.vaines.org/posts/2026-03-24-the-comforting-lie-of-sha-pinning/

In March 2026, Trivy became the latest reminder that software supply chains are, at best, loosely held together with convention and trust.

A typosquatting attack slipped malicious code into what looked like a legitimate dependency path. The post-mortems are worth reading, and they all converge on a single recommendation: pin your dependencies. In the GitHub Actions world, that usually translates to use commit SHAs, not tags.

There’s a widely held belief that pinning a GitHub Action to a commit SHA gives you immutability, its what Microsoft/GitHub are recommending, and its what Aqua are recommending. After all, a SHA is content-addressed. It cannot be moved. It cannot be re-tagged. It is, in theory, the most stable reference you can use. The problem with that line of thinking is that the resolution of that SHA is not scoped the way most people assume. Specifically, GitHub Actions does not meaningfully validate that the commit SHA you reference belongs to the repository you think it does.

Wait, what? No, thats not right...

I set up a deliberately small example to test this behaviour.

A “legitimate” action: avaines/blog_gh_sha_pinning_action
A consuming application: avaines/blog_gh_sha_pinning_app

The application references the action in the usual way:

uses: avaines/blog_gh_sha_pinning_action@<some-sha>

So far, so normal.

Now introduce an attacker:

Fork the action repository to aidenvaines-cgi/blog_gh_sha_pinning_action
Add a malicious step (in my case, just printing output, but in reality this is where you exfiltrate all the fun stuff like secrets and personal data)

Next, create a pull request to the consuming application that appears to simply bump the pinned SHA:

The SHA used in the PR comes from the attacker-controlled fork of the action, despite it still being referenced as avaines/blog_gh_sha_pinning_action

You might reasonably assume one of the following safeguards exists:

GitHub validates that the SHA belongs to avaines/blog_gh_sha_pinning_action
Or the workflow fails because the commit cannot be found in the specified repository

Neither is true, and that is madness

The workflow executes successfully!!!!!!!

GitHub resolves the commit SHA, finds a matching object, and executes it, regardless of which fork it originated from.

From the platform’s perspective, a fork is a separate repository with a shared object graph/history. When the runner resolves the reference, it ultimately looks up the commit in the Git object database; if that object exists and is reachable, it can be used regardless of which fork introduced it. A commit object is globally identifiable. If the SHA exists anywhere reachable, that is apparently sufficient.

The result is that a pull request can replace a pinned, trusted action with attacker-controlled code without changing the apparent repository reference.

If the reviewer is scanning for obvious changes like owner, repo name, or tag they will see none.

Only the SHA changes and with that comes a huge amount of assumed trust. I know that owner, and I know that repository, its just a version bump, and a minor one at that, with that comment next to the tag doing a lot of heavy lifting. We’ve just spent the last few years training people to treat that as best practice.

A lot of the current guidance focuses on avoiding tags because they are mutable, which is true: tags can be moved, and relying on them introduces an entirely different risk. Github already has a 'Make tags immutable' feature, but it's optional, therefore, neither used nor can it be trusted as the owner (or attacker) could just disable it.

Simply switching to SHA pinning does not eliminate the problem, in some respects it makes it worse. Tags are scoped to owner/repository because thats how they work. You could argue its harder to compromise that repository rather than hijack it through a forked repository and then writing actual changes to the repository. Whereas a commit object is content-addressed and can be reachable from multiple repositories that share history (e.g. forks)

I believe the industry advice is a bit of an overcorrection, and we’ve replaced one weak guarantee (mutable tags but scoped to repo) with another vastly worse idea in unscoped SHAs. Yes you should check, yes you should validate it, but tags are human readable, SHAs are not and if you ask yourself "Do I always properly check?" do you? because I can't say I do enough validation 100% of the time.

Supply Chain Woes

The Trivy incident is not interesting because of the tool. Though it is the thing that's caused me a lot of bother over the last month, and its symptomatic of the constant supply chain threats we're seeing everywhere. Late last year NPM was basically a skip fire (https://www.wiz.io/blog/widespread-npm-supply-chain-attack-breaking-down-impact-scope-across-debug-chalk, https://www.wiz.io/blog/shai-hulud-npm-supply-chain-attack, etc). We've delegated so much behaviour to 3rd parties we can't, and shouldn't implicitly trust. The https://www.npmjs.com/package/is-odd package became a bit of a meme for this exact problem, where tool chains like NPM and GitHub Actions place re-usable custom modules/actions/libraries as an attractive off the shelf solution to solve common problems so you don't have to.

Ironically with the rise of AI, it's now easier to just vibe code the same functionality yourself that use one of these off the shelf resources, and you can still know exactly as much about how security, your data, and to some extent the functionality works with strangely more ownership and a smaller attack service.

GitHub Actions, in particular exacerbates this somewhat as workflows routinely execute third-party code, the secrets are implicitly available to those workflows and there are multiple ways to extract those at runtime with little audit or oversight. Then to top it all off SHAs are not human friendly and tags are not immutable so review processes tend to focus on what changed, not *where it came from. Which is all a fragile house of cards, sometimes I miss Jenkins.

If “use SHAs” is not sufficient, what is?

At a minimum, we need to introduce provenance checks. I've said above that SHA's are not human friendly like tags so theres a couple of things we can, and probably should be doing to validate. Obviously that the SHA or tag exists in the right repository and GitHub should enforce tag mutability in my opinion:

We tend to describe these incidents as “supply chain attacks”, which is accurate but slightly misleading. It implies a complex and sophisticated multi-stage compromise by 1337 h4x0rz. In reality, the weakest link is often much simpler because humans are a bit shit sometimes. SHA pinning being touted as the solution is just security-theater rather than due diligence in an ecosystem that is not helping either.

Minha Experiência Estruturando uma Pipeline Mobile CI/CD Flutter

Fri, 08 May 2026 12:19:10 +0000

Recentemente, enfrentei o desafio de estruturar uma pipeline de CI/CD completa para um aplicativo corporativo desenvolvido em Flutter. O objetivo era claro: automatizar, proteger e agilizar o deploy para Android e iOS. Neste artigo, compartilho os aprendizados, as soluções para os obstáculos encontrados e os exemplos práticos que formaram a espinha dorsal dessa implementação.

Por que investir em CI/CD mobile?

Em um cenário de desenvolvimento ágil, automatizar os processos de build, teste e deploy não é um luxo, mas uma necessidade. Para aplicações mobile, essa urgência é amplificada: os builds são demorados e consomem recursos, as dependências evoluem rapidamente e cada loja de aplicativos (Google Play e App Store) impõe seu próprio conjunto de regras e exigências. Uma pipeline bem arquitetada garante entregas rápidas, seguras e com a consistência que um ambiente corporativo exige.

Estrutura dos Workflows

Para organizar o processo, a pipeline foi modularizada em workflows distintos no GitHub Actions. Cada workflow é uma sequência de jobs que rodam em ambientes específicos, conhecidos como runners.

Runners: São as máquinas virtuais que executam seus jobs. Para builds Android, utilizamos os runners ubuntu-latest fornecidos pelo GitHub, que são eficientes e econômicos. Para iOS, a compilação exige o macOS. Como os runners macOS do GitHub têm um custo associado, optamos por configurar um runner self-hosted em uma máquina Mac local, garantindo controle total sobre o ambiente e otimização de custos.

Dividimos nossa esteira em workflows específicos, cada um com sua responsabilidade:

feature-workflow.yml: Valida código novo, executa lint, testes unitários e análise SAST (Static Application Security Testing), garantindo qualidade e segurança desde o início.
staging-workflow.yml: Prepara builds de homologação, rodando validações e testes automatizados.
mobile-workflow.yml: Geram builds de produção e fazem o deploy para Google Play e App Store.

Controle dos Fluxos

Para garantir que cada etapa só rode no momento certo e que a pipeline de produção só seja executada após a validação em staging, utilizei gatilhos condicionais. Isso orquestra a transição entre ambientes de forma segura.

on:
  workflow_dispatch: # Permite disparo manual
  workflow_run:
    workflows: ["staging-workflow"] # Nome do workflow que deve terminar
    types:
      - completed # Apenas quando ele for concluído

jobs:
  build:
    # A condição abaixo garante que o job só rode se o disparo for manual
    # ou se o workflow de staging anterior tiver sido concluído com sucesso.
    if: >
      github.event_name == 'workflow_dispatch' ||
      (github.event.workflow_run.conclusion == 'success' && github.event.workflow_run.head_branch == 'staging')
    runs-on: ubuntu-latest
    ...

Isso permite que o workflow seja disparado manualmente ou automaticamente após a conclusão bem-sucedida do workflow de staging. O uso do workflow_dispatch também foi essencial para execuções manuais e testes pontuais.

Configuração do Ambiente

Antes de qualquer build, preparei o ambiente instalando Flutter, Java e aplicando cache para dependências, acelerando o processo e evitando downloads desnecessários:

- name: Setup Flutter
  uses: subosito/flutter-action@v2
  with:
    flutter-version: ${{ env.FLUTTER_VERSION }}
    channel: stable
    cache: true

- name: Cache Flutter pub dependencies
  uses: actions/cache@v4
  with:
    path: ~/.pub-cache
    key: ${{ runner.os }}-pub-${{ env.FLUTTER_VERSION }}-${{ hashFiles('**/pubspec.lock') }}

- name: Setup Java
  uses: actions/setup-java@v4
  with:
    distribution: 'temurin'
    java-version: '17'

No iOS, também utilizei cache para CocoaPods e limpei o ambiente antes de cada build:

- name: Cache CocoaPods
  uses: actions/cache@v4
  with:
    path: ios/Pods
    key: ${{ runner.os }}-pods-${{ hashFiles('**/pubspec.lock') }}

Assinatura dos Apps

A assinatura digital é obrigatória para publicação nas lojas. No Android, trabalhei com keystore e no iOS, com certificados e provisioning profiles:

- name: Setup iOS certificates
  uses: apple-actions/import-codesign-certs@v2
  with:
    p12-file-base64: ${{ secrets.CERTIFICATE_BASE64 }}
    p12-password: ${{ secrets.CERTIFICATE_PASSWORD }}

- name: Download Provisioning Profiles
  uses: apple-actions/download-provisioning-profiles@v2
  with:
    bundle-id: com.seuapp.id
    profile-type: IOS_APP_STORE
    issuer-id: ${{ secrets.APPSTORE_ISSUER_ID }}
    api-key-id: ${{ secrets.APPSTORE_KEY_ID }}
    api-private-key: ${{ secrets.APPSTORE_PRIVATE_KEY }}

O GitHub trabalha de uma forma bem peculiar com certificados, exigindo que o sejam salvos como secret em base64 e decodificado em tempo de execução no runner.

No Android, o keystore foi salvo via secret em base64 e decodificado no runner:

- name: Setup Android signing
  run: |
    echo "$KEYSTORE_BASE64" | base64 -d > android/app/keystore.jks

Jobs de Qualidade

Implementei jobs de lint, testes unitários e análise estática de segurança (SAST) para garantir qualidade e segurança:

- name: Lint Flutter
  run: flutter analyze

- name: Testes Unitários
  run: flutter test --coverage

- name: SAST com MobSF
  uses: MobSF/mobsfscan@main
  with:
    args: .

O SAST foi crucial para identificar vulnerabilidades cedo, especialmente em apps que lidam com dados sensíveis. Cada job gera relatórios que ajudam a manter a qualidade do código alta.

Deploy Automatizado

Com os builds assinados, o último passo é o deploy, utilizei actions específicas para upload dos builds:

Android:
r0adkll/upload-google-play@v1 para enviar o bundle diretamente à Google Play.
iOS:
apple-actions/upload-testflight-build@v3 para subir o IPA ao TestFlight.

Exemplo de upload para TestFlight:

- name: Upload app to TestFlight
  uses: apple-actions/upload-testflight-build@v3
  with: 
    app-path: ${{ steps.find-ipa.outputs.ipa-path }}
    issuer-id: ${{ secrets.APPSTORE_ISSUER_ID }}
    api-key-id: ${{ secrets.APPSTORE_KEY_ID }}
    api-private-key: ${{ secrets.APPSTORE_PRIVATE_KEY }}

Dificuldades e Aprendizados

Um dos maiores desafios foi adaptar o pipeline iOS para rodar em runner Mac self-hosted, já que o GitHub Actions não oferece MacOS gratuito. Também precisei ajustar versões de Java e Gradle para evitar conflitos e falhas silenciosas nos builds Android.

No fim, consegui uma esteira automatizada, segura e eficiente, que valida, testa, assina e publica os apps nas lojas com mínimo esforço manual. Se você está montando sua pipeline mobile, recomendo investir tempo nos jobs de qualidade, na configuração de secrets e no controle dos fluxos. O resultado compensa!

Deploying a Simple App on K3S in AWS EC2 with GitHub Actions & ECR

Tue, 24 Mar 2026 10:36:12 +0000

title: Deploying a Simple App on K3S in AWS EC2 with GitHub Actions & ECR
published: true
date: 2025-09-07 12:15:31 UTC
tags: github,kubernetes,kubernetescluster,githubactions

canonical_url: https://medium.com/@mahinshanazeer/deploying-a-simple-app-on-k3s-in-aws-ec2-with-github-actions-ecr-58e0ea29eb2a

In this session, we’ll walk through the configuration of K3S on an EC2 instance and deploy a multi-container application with a frontend, backend, and database. The application will run inside a Kubernetes cluster using Deployments and StatefulSets in headless mode. For the setup, we’ll use EC2 to host the cluster, GitHub as our code repository, and GitHub Actions to implement CI/CD.

If you’re an absolute beginner and not familiar with configuring EC2, I recommend checking out my blog here:

Step-by-Step Guide to Launching an EC2 Instance on AWS : For Beginners

This will be an end-to-end project deployment designed for those learning K3S, CI/CD, and Docker. You’ll gain hands-on experience in setting up CI/CD pipelines, writing Dockerfiles, and using Docker Compose. We’ll then move on to deploying the application in K3S, working with Kubernetes manifests, and exploring key components such as Deployments, Services (NodePort and ClusterIP), ConfigMaps, Persistent Volumes (PV), Persistent Volume Claims (PVC), and StatefulSets.

K3S is a lightweight Kubernetes distribution developed by Rancher (now SUSE). It’s designed to be:

Lightweight — small binary, minimal dependencies.

Easy to install — single command installation.

Optimized for edge, IoT, and small clusters — runs well on low-resource machines like Raspberry Pi or small EC2 instances.

Fully compliant — supports all standard Kubernetes APIs and workloads.

In short, K3S simplifies Kubernetes and makes it resource-efficient, making it ideal for single-node clusters, test environments, and learning purposes.

Log login to the EC2 machine and install k3s first:

K3s

You can install K3S on your machine using the following single command:

sudo apt update -y && sudo apt upgrade -y
curl -sfL https://get.k3s.io | sh - 
# Check for Ready node, takes ~30 seconds 
sudo k3s kubectl get node

Installation of k3s

Once the installation is completed, the output should be similar to this:

Kubectl node status

Once the cluster is up and running, we can move on to the application. You can refer to the following repository for the demo To-Do List app. Before cloning the repository, make sure Docker is installed on the machine to build and test the application. For installing Docker, refer to the following URL:

Ubuntu

#run the following command first to remove conficting packages

for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do sudo apt-get remove $pkg; done

# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update

#Installing Docker
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

#Now verify the installtion.
sudo docker run hello-world

Now, let’s dive into the demo application. The Application Stack:

Frontend: React.js
Backend API: Node.js + Express
Database: MongoDB
Containerization & Registry: Docker + AWS ECR
Orchestration & Service Management: Kubernetes (K3s)

Next, let’s clone the application repository to your local machine.

GitHub - mahinshanazeer/docker-frontend-backend-db-to_do_app: Simple Application with Frontend + Backened + DB

git clone https://github.com/mahinshanazeer/docker-frontend-backend-db-to_do_app

Clone the github application

Once the repository is cloned, switch to the application directory and check for the Docker Compose file.

Directory structure

version: "3.8"
services:
  web:
    build:
      context: ./frontend
      args:
        REACT_APP_API_URL: ${REACT_APP_API_URL}
    depends_on:
      - api
    ports:
      - "3000:80"
    networks:
      - network-backend
    env_file:
      - ./frontend/.env

  api:
    build: ./backend
    depends_on:
      - mongo
    ports:
      - "3001:3001"
    networks: 
      - network-backend
  
  mongo:
    build: ./backend-mongo  
    image: docker-frontend-backend-db-mongo
    restart: always
    volumes: 
      - ./backend-mongo/data:/data/db
    environment: 
      MONGO_INITDB_ROOT_USERNAME: admin
      MONGO_INITDB_ROOT_PASSWORD: adminhackp2025
    networks: 
      - network-backend

networks:
  network-backend:

volumes: 
  mongodb_data:

In the Docker Compose file, you’ll see sections for web, api, and mongo. Let’s dive into each directory and review the Dockerfiles. The Docker Compose file builds the Docker images using the Dockerfiles located in their respective directories.


root@ip-172-31-22-24:/home/ubuntu/docker-frontend-backend-db-to_do_app/frontend# cd /home/ubuntu/docker-frontend-backend-db-to_do_app/frontend
root@ip-172-31-22-24:/home/ubuntu/docker-frontend-backend-db-to_do_app/frontend# cat Dockerfile 
# ---------- Build Stage ----------
FROM node:16-alpine AS build

WORKDIR /app

# Copy dependency files first
COPY package*.json ./

# Install dependencies
RUN npm install --legacy-peer-deps

# Copy rest of the app
COPY . .

# Build the React app
RUN npm run build

# ---------- Production Stage ----------
FROM nginx:alpine

# Copy custom nginx config if you have one
# COPY nginx.conf /etc/nginx/conf.d/default.conf

# Copy build output from build stage
COPY --from=build /app/build /usr/share/nginx/html

# Expose port 80
EXPOSE 80

# Start nginx
CMD ["nginx", "-g", "daemon off;"]

***

root@ip-172-31-22-24:/home/ubuntu/docker-frontend-backend-db-to_do_app/backend# cd /home/ubuntu/docker-frontend-backend-db-to_do_app/backend
root@ip-172-31-22-24:/home/ubuntu/docker-frontend-backend-db-to_do_app/backend# cat Dockerfile 
FROM node:10-alpine

WORKDIR /usr/src/app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 3001

***

root@ip-172-31-22-24:/home/ubuntu/docker-frontend-backend-db-to_do_app/backend# cd /home/ubuntu/docker-frontend-backend-db-to_do_app/backend-mongo/
root@ip-172-31-22-24:/home/ubuntu/docker-frontend-backend-db-to_do_app/backend-mongo# cat Dockerfile 
FROM mongo:6.0
EXPOSE 27017

Open the .env file in the frontend directory and update the IP address to your EC2 public IP. This environment variable is used by the frontend to connect to the backend, which runs on port 3001.

vi /home/ubuntu/docker-frontend-backend-db-to_do_app/frontend/.env

#edit the IP address, I have updated my EC2 public IP
~~~
REACT_APP_API_URL=http://54.90.185.176:3001/
~~~

We can also cross-check the total number of APIs using the following commands:

grep -R "router." backend/ | grep "("
grep -R "app." backend/ | grep "("
grep -R "app." backend/ | grep "(" | wc -l
grep -R "router." backend/ | wc -l

Let’s test the application by spinning up the containers. Navigate back to the project’s root directory and run the Docker Compose command.

cd /home/ubuntu/docker-frontend-backend-db-to_do_app
docker compose up -d

Once you run the command, Docker will start building the images and spin up the containers as soon as the images are ready

building docker containers

Wait until you see the ‘built’ and ‘created’ messages. Once the containers are up and running, use docker ps -a to verify the status.

build completed and containers started.

docker ps -a

docker processes

Once the Docker containers are up and running, verify that the application is working as expected.

Once the Docker containers are up and running, verify that the application is working as expected. Open the server’s IP address on port 3000. You can confirm the mapped ports in the Docker Compose file or by checking the docker ps -a output. Here, port 3000 is for the frontend web app, port 3001 is for the backend, and MongoDB runs internally on port 27017 without public access. In this example, load the website by entering 54.90.185.176:3000 in your browser.

Application interface

If you’re using Chrome, right-click anywhere on the page and open Inspect > Network. Then click on Add Todo to verify that the list updates correctly, and the network console shows a 200 status response

checking the network

Application testing

Click on the buttons and try to add new file, and verify the status codes:

Testing

So far, everything looks good. Now, let’s proceed with the Kubernetes deployment. To configure resources in Kubernetes, we’ll need to create manifest files in YAML format. You can create these files as shown below.

mkdir /home/ubuntu/manifest
touch api-deployment.yaml api-service.yaml image_tag.txt mongo-secret.yaml mongo-service.yaml mongo-statefulset-pv-pvc.yaml web-deployment.yaml web-env-configmap.yaml web-service.yaml

Now edit each file and add the following contents:

api-deployment.yaml:

Defines how the backend API should run inside the cluster.

Creates 2 replicas of the API for reliability.

Uses environment variables from secrets for MongoDB authentication.

Ensures the API pods always restart if they fail.

Importance: Provides scalability and fault tolerance for the backend service.

Rolling Update: Gradually replaces old pods with new ones. Uses fewer resources, minimal downtime if tuned, but users may hit bad pods if the new version is faulty.

Rolling = efficient and native.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  labels:
    app: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 3
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: 495549341534.dkr.ecr.us-east-1.amazonaws.com/hackp2025:api-20250907111542
          ports:
            - containerPort: 3001
          env:
            - name: MONGO_INITDB_ROOT_USERNAME
              valueFrom:
                secretKeyRef:
                  name: mongo-secret
                  key: username
            - name: MONGO_INITDB_ROOT_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mongo-secret
                  key: password
      restartPolicy: Always

api-service.yaml

Exposes the API deployment to the outside world.

Type NodePort makes the service reachable via :31001.

Ensures frontend or external clients can communicate with the backend.

Importance: Acts as a bridge between users/frontend and the backend API.

apiVersion: v1
kind: Service
metadata:
  name: api
  labels:
    app: api
spec:
  type: NodePort
  selector:
    app: api
  ports:
    - port: 3001 # internal cluster port
      targetPort: 3001 # container port
      nodePort: 31001 # external port on the node

mongo-secret.yaml

Stores sensitive information (username & password) in base64-encoded format.

Used by both the API and MongoDB.

Keeps credentials out of plain-text manifests.

Importance: Secure way to handle database credentials.

apiVersion: v1
kind: Secret
metadata:
  name: mongo-secret
type: Opaque
data:
  # Base64 encoded values
  username: YWRtaW4= # "admin"
  password: YWRtaW5oYWNrcDIwMjU= # "adminhackp2025"

mongo-service.yaml

Defines the MongoDB service.

- ClusterIP: None makes it a headless service , required for StatefulSets.

Allows pods to connect to MongoDB by DNS (e.g., mongo-0.mongo).

Importance: Provides stable networking for MongoDB StatefulSet pods.

apiVersion: v1
kind: Service
metadata:
  name: mongo
  labels:
    app: mongo
spec:
  ports:
    - port: 27017
      targetPort: 27017
  selector:
    app: mongo
  clusterIP: None # headless service for StatefulSet

mongo-statefulset-pv-pvc.yaml

Handles the database persistence and StatefulSet definition.

- PersistentVolume (PV): Reserves storage (5Gi).

- PersistentVolumeClaim (PVC): Ensures pods can claim storage.

- StatefulSet: Guarantees stable network identity and persistent storage for MongoDB.

Importance: Ensures MongoDB data is preserved even if the pod restarts.

Blue/Green Deployment: Runs two environments (Blue = live, Green = new). Traffic is switched instantly once Green is ready. Near-zero downtime and easy rollback, but requires double resources and is more complex for stateful apps.

Blue/Green = safer cutover, higher cost.

# PersistentVolume for Green MongoDB
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mongo-green-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /root/hackpproject/data-green # separate path for green
  persistentVolumeReclaimPolicy: Retain
  storageClassName: "" # Must match PVC in StatefulSet

---

# StatefulSet for Green MongoDB
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mongo-green
  labels:
    app: mongo
    version: green
spec:
  serviceName: mongo # existing headless service
  replicas: 1
  selector:
    matchLabels:
      app: mongo
      version: green
  template:
    metadata:
      labels:
        app: mongo
        version: green
    spec:
      containers:
        - name: mongo
          image: 495549341534.dkr.ecr.us-east-1.amazonaws.com/hackp2025:db-20250907111542
          ports:
            - containerPort: 27017
          env:
            - name: MONGO_INITDB_ROOT_USERNAME
              valueFrom:
                secretKeyRef:
                  name: mongo-secret
                  key: username
            - name: MONGO_INITDB_ROOT_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mongo-secret
                  key: password
          volumeMounts:
            - name: mongo-data
              mountPath: /data/db
  volumeClaimTemplates:
    - metadata:
        name: mongo-data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 5Gi
        storageClassName: "" # binds to the pre-created PV

web-deployment.yaml

Defines how the frontend (React.js app) should run.

Runs 2 replicas for high availability.

Pulls API endpoint from ConfigMap.

Resource requests/limits ensure fair scheduling.

Importance: Deploys the UI and links it to the backend API via config.

Rolling Update: Gradually replaces old pods with new ones. Uses fewer resources, minimal downtime if tuned, but users may hit bad pods if the new version is faulty.

Rolling = efficient and native.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 3         
      maxUnavailable: 0   
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: 495549341534.dkr.ecr.us-east-1.amazonaws.com/hackp2025:web-20250907111542
          ports:
            - containerPort: 3000
              protocol: TCP
          env:
            - name: REACT_APP_API_URL
              valueFrom:
                configMapKeyRef:
                  name: web-env
                  key: REACT_APP_API_URL
          resources:
            requests:
              cpu: "200m"
              memory: "1024Mi"
            limits:
              cpu: "2"
              memory: "2Gi"
      restartPolicy: Always

web-env-configmap.yaml

Stores non-sensitive environment variables.

Defines the API endpoint for the frontend (REACT_APP_API_URL).

Can be updated easily without rebuilding Docker images.

Importance: Provides flexibility to change configuration without redeploying code.

apiVersion: v1
kind: ConfigMap
metadata:
  name: web-env
  labels:
    app: web
data:
  REACT_APP_API_URL: http://98.86.216.31:31001

web-service.yaml

Exposes the frontend to users.

- Type NodePort makes it available externally at :32000.

Maps port 3000 (service) → port 80 (container).

Importance: Allows end-users to access the web app from their browser.

apiVersion: v1
kind: Service
metadata:
  name: web
  labels:
    app: web
spec:
  type: NodePort
  selector:
    app: web # Must match Deployment labels
  ports:
    - name: http
      port: 3000 # Service port inside cluster
      targetPort: 80 # Container port
      nodePort: 32000 # External port accessible from outside

We have now moved all the manifest files to /root/hackpproject/manifestfiles.

Once the manifests are finalised, the next step is to create a repository in ECR to push the build artefact images.

Steps to Create an ECR Repository:
1.Log in to AWS Console → Go to the ECR service.

Create Repository

Click Create repository.

Select Private repository.

Enter repository names — prodimage. (In this case, we are creating a single repository for all those 3 images)

Leave others as default and click Create repository.

Authenticate Docker with ECR

Step 1: Finding the ECR

Step 2: Creating Repository

Step 3: onfiguring Repository

Once the registry is created, you can proceed with the CI/CD pipeline.

Reposiroty end point

Now, let’s create a GitHub Actions pipeline to deploy the code to the EC2 K3S cluster. The first step is to configure GitHub Actions with access to the repository, ECR, and the EC2 instance via SSH.

Navigate to the project directory and create a folder named ‘.github’. Inside this folder, create a file named ‘ci-cd.yml’.

mkdir .github
cd .github
touch ci-cd.yml
vi ci-cd.yml

The ci-cd.yml file is the core configuration file for GitHub Actions that defines your CI/CD pipeline. Now use the following script in that ci-cd.yml file:

name: CI/CD Pipeline

on:
  push:
    branches:
      - main

jobs:
  build-and-deploy:
    runs-on

Coder Legion - Recent posts tagged githubactions

Dynamic GitHub Actions Dropdowns — A Clever Workaround Made Reusable!

My First Project: From a Local Folder to GitHub Using Git and SSH

My First Project: From a Local Folder to Git hub Using Git and SSH

GIT

Introduction

Installing Git

Configuring Git

SSH

Generating an SSH Key

Adding Your Key to GitHub

Working With Folders

Working With Files

Your First Project

Initialize your first project with git

Git repository structure.

Checking the project status

Staging your project files

Commiting you staged files

Uploading to git-hub

Creating a remote repository

Connecting our local and remote repositories

Rename your branch

Check the remote

Push your project to git-hub

Summary

AURA v0.1.0: Deterministic Trigger Extraction, Auditable Math & a Self-Healing Analytics Engine

1. System Architecture at a Glance

2. Non-Linear Risk Normalization: Why We Don't Just "Sum Things Up"

Tuning Sensitivity (\({\alpha}\))

3. Hardening Trigger Extraction: Sliding Windows & Contextual Anchors

Sliding Window Engine

Contextual Anchors vs. Co-Occurrence Cues

4. Solving the GitHub Traffic "Blind Spot" (Because 14 Days Is Not "Project Growth")

How the Analytics Snapshot Pipeline Works:

5. Community Spotlight: Catching a Subtle Async Race Condition

6. Roadmap (What Realistically Comes Next)

Closing Notes

Demystifying the Ghost Failure in Firebase Hosting GitHub Actions

Lazy SRE's guide to secure systems, part 2: the actions you didn't pin

pinning is necessary but not sufficient

cooldown is the same trick that worked for npm

pull_request_target is the new postinstall

the safe defaults that go in every workflow

OIDC, the promise from part 1

zizmor is the local proxy for workflows

the receipts

The Comforting Lie Of SHA Pinning

Wait, what? No, thats not right...

Supply Chain Woes

If “use SHAs” is not sufficient, what is?

Minha Experiência Estruturando uma Pipeline Mobile CI/CD Flutter

Por que investir em CI/CD mobile?

Estrutura dos Workflows

Controle dos Fluxos

Configuração do Ambiente

Assinatura dos Apps

Jobs de Qualidade

Deploy Automatizado

Dificuldades e Aprendizados

Deploying a Simple App on K3S in AWS EC2 with GitHub Actions & ECR

canonical_url: https://medium.com/@mahinshanazeer/deploying-a-simple-app-on-k3s-in-aws-ec2-with-github-actions-ecr-58e0ea29eb2a