Coder Legion - Recent posts tagged github-actions

Segurança em CI/CD: a importância de estudar, auditar e aprender com pipelines de bons projetos

Fri, 30 Oct 2026 12:10:32 +0000

Pipelines de CI/CD são frequentemente tratados como simples mecanismos de automação: executam testes, compilam aplicações, geram artefatos e realizam deploys. Entretanto, eles também representam uma das superfícies de ataque mais importantes de um ambiente de desenvolvimento moderno.

Um pipeline possui acesso a repositórios, tokens, credenciais, registries, ambientes de produção, dependências externas e, em muitos casos, permissões para modificar recursos de infraestrutura. Isso significa que uma falha na configuração de um workflow pode ultrapassar os limites do processo de build e comprometer toda a cadeia de entrega de software.

Por esse motivo, estudar a segurança de pipelines deve fazer parte da rotina de engenharia, assim como revisar código, analisar dependências e avaliar configurações de infraestrutura.

Mais importante do que simplesmente executar ferramentas de análise é compreender por que determinada configuração representa um risco, em quais condições ela pode ser explorada e quais mecanismos realmente mitigam esse risco.

1. Por que estudar pipelines é tão importante?

Um pipeline inseguro pode transformar uma alteração aparentemente simples em um vetor de comprometimento.

Considere alguns exemplos:

Um Pull Request pode introduzir código executado em um runner que possui acesso a credenciais.
Uma interpolação insegura de contextos do GitHub pode permitir injeção de comandos no shell.
Uma dependência comprometida pode executar código durante a instalação.
Um token com permissões excessivas pode permitir alterações não autorizadas no repositório.
Uma publicação sem mecanismos adequados de autorização pode disponibilizar uma versão não aprovada de um pacote.
Um workflow mal configurado pode executar código de terceiros com privilégios superiores aos necessários.

Esses cenários demonstram que o pipeline não é apenas uma ferramenta operacional. Ele faz parte da infraestrutura de segurança da organização.

A segurança precisa considerar todo o ciclo de execução: desde o evento que dispara o workflow até as permissões disponíveis, dependências instaladas, artefatos produzidos e operações realizadas.

2. Utilize scanners, mas não terceirize o julgamento técnico

Existem ferramentas especializadas em identificar configurações inseguras em workflows.

Algumas opções relevantes que eu utilizo no dia a dia para scans do pipeline:

zizmor: analisa workflows do GitHub Actions e identifica problemas como template injection, permissões inadequadas, uso inseguro de eventos e instalações de dependências fora de manifests.
Checkov: realiza análise estática de configurações de infraestrutura como código e também identifica problemas em configurações de CI/CD.
actionlint: valida a sintaxe, expressões, referências e possíveis problemas estruturais em workflows do GitHub Actions.
OpenSSF Scorecard: avalia práticas de segurança de projetos e repositórios, incluindo dependências, permissões, manutenção e configuração de workflows.
Trivy: além de analisar imagens e dependências, consegue avaliar configurações e arquivos de infraestrutura.

Essas ferramentas são importantes porque automatizam a identificação de padrões conhecidos de risco.

Entretanto, existe uma diferença fundamental entre encontrar uma configuração potencialmente insegura e demonstrar que ela é explorável.

Um scanner identifica padrões. O engenheiro precisa compreender o contexto.

Exemplo: template injection

Considere:

- name: Check changelog
  run: scripts/check-changelog-frozen.sh "origin/${{ github.base_ref }}"

O scanner pode identificar uma possível injeção de comandos porque o contexto é interpolado diretamente no código executado pelo shell.

O risco existe porque o GitHub Actions realiza a expansão da expressão antes de executar o script.

Entretanto, é necessário entender a origem do dado.

github.base_ref representa a branch de destino do Pull Request, enquanto github.head_ref representa a branch de origem.

Um colaborador externo normalmente controla o nome da própria branch, mas não controla livremente a branch de destino.

Portanto, embora exista um padrão vulnerável, a explorabilidade depende das permissões e das condições do workflow.

A correção recomendada é transportar o valor por uma variável de ambiente:

- name: Check changelog
  env:
    BASE_REF: ${{ github.base_ref }}
  run: scripts/check-changelog-frozen.sh "origin/$BASE_REF"

O valor passa a ser tratado como dado, em vez de ser inserido diretamente no código interpretado pelo shell.

Esse exemplo demonstra por que é necessário estudar os findings: o scanner identifica corretamente o padrão, mas a análise de impacto exige conhecimento sobre os contextos do GitHub Actions.

3. Aprenda a diferenciar vulnerabilidades reais de findings parcialmente mitigados

Nem todo alerta representa uma vulnerabilidade diretamente explorável.

Um exemplo interessante é a instalação de dependências durante o pipeline.

Considere:

env:
  CLAUDE_CODE_VERSION: "2.1.296"
  CODEX_VERSION: "0.162.1"

E posteriormente:

- name: Install CLIs
  run: |
    npm install --global \
      "@anthropic-ai/claude-code@${CLAUDE_CODE_VERSION}" \
      "@openai/codex@${CODEX_VERSION}"

Um scanner como o zizmor pode identificar o padrão adhoc-packages, pois os pacotes são instalados globalmente sem um manifesto e lockfile controlando a instalação.

Entretanto, existe uma particularidade: as versões principais já estão explicitamente fixadas.

Isso significa que o workflow não está simplesmente instalando a última versão disponível a cada execução.

Ainda existe uma fragilidade: a árvore completa de dependências não está necessariamente reproduzível, pois as dependências transitivas não são controladas por um lockfile versionado.

É importante distinguir:

Versão principal fixada: controla qual versão direta será solicitada.
Manifesto: declara as dependências do projeto.
Lockfile: registra a resolução das dependências e suas integridades.
Instalação reproduzível: utiliza a resolução registrada para reconstruir o ambiente.

A ausência de lockfile continua sendo um finding válido, mas não significa automaticamente que existe uma instalação de versão flutuante ou que um pacote esteja comprometido.

O objetivo da análise não é eliminar alertas indiscriminadamente, mas determinar quais riscos permanecem e quais controles já existem.

4. Estude como projetos maduros resolvem problemas de segurança

Uma das formas mais eficientes de evoluir na segurança de pipelines é estudar workflows de projetos open source bem mantidos.

Em vez de começar sempre do zero, investigue como projetos com grande exposição pública estruturam seus processos de CI/CD.

Alguns exemplos interessantes para estudo:

Kubernetes: organização de workflows, testes, automação e governança de contribuições.
Terraform: validação, testes, releases e publicação de artefatos.
Trivy: análise de segurança, integração de scanners e automação de releases.
OpenTelemetry: testes distribuídos, validação de componentes e publicação de versões.
actions/checkout: implementação e manutenção de GitHub Actions.
Sigstore: assinatura, verificação e estabelecimento de confiança em artefatos.

Ao estudar esses projetos, não observe apenas quais actions são utilizadas. Investigue as decisões arquiteturais.

Pergunte:

Como o workflow é disparado?
Ele aceita Pull Requests de forks?
Quais permissões são concedidas ao GITHUB_TOKEN?
Existem secrets disponíveis durante a execução?
Como as dependências são instaladas?
As GitHub Actions são referenciadas por tags ou hashes SHA completos?
Como os artefatos são assinados e verificados?
Como as publicações são autorizadas?
Existem ambientes protegidos e aprovações humanas?
Como o projeto separa testes, validação e publicação?

O objetivo é compreender o motivo de cada decisão, e não simplesmente copiar configurações.

Uma configuração segura em determinado contexto pode ser inadequada em outro.

5. Construa uma rotina de auditoria de pipelines

A análise não deve acontecer somente quando um scanner encontra um problema.

Uma rotina de auditoria pode ser incorporada ao próprio processo de engenharia.

Uma abordagem prática:

Etapa 1 — Inventário

Mapear todos os workflows existentes:

CI.
CD.
Release.
Publicação de pacotes.
Provisionamento de infraestrutura.
Automação de dependências.
Segurança e compliance.

Etapa 2 — Análise automatizada

Executar ferramentas como:

zizmor .github/workflows

actionlint

checkov -d .github/workflows

scorecard --repo=github.com/ORG/REPOSITORY

Os comandos devem ser ajustados à versão e à forma de instalação de cada ferramenta.

Etapa 3 — Investigação dos findings

Para cada alerta:

Identificar o trecho responsável.
Entender a regra acionada.
Identificar a origem dos dados.
Verificar se existe controle compensatório.
Avaliar a possibilidade de exploração.
Determinar o impacto potencial.
Definir a correção ou justificar uma exceção.

Etapa 4 — Correção

Priorizar problemas que permitam execução de código não confiável, exposição de credenciais, elevação de privilégios e comprometimento de releases.

Etapa 5 — Prevenção

Incorporar os scanners ao próprio CI para impedir que configurações inseguras sejam introduzidas novamente.

6. Crie um laboratório utilizando projetos reais

Uma estratégia especialmente interessante é escolher projetos open source e realizar auditorias independentes em seus workflows.

Não é necessário encontrar uma vulnerabilidade para que o estudo seja útil.

O exercício consiste em:

Selecionar um repositório ativo e bem mantido.
Baixar ou clonar seus workflows.
Executar os scanners.
Investigar os findings.
Consultar a documentação das regras acionadas.
Comparar a implementação com as recomendações oficiais.
Identificar controles compensatórios.
Propor correções.
Registrar os resultados em um pequeno relatório técnico.

É possível inclusive comparar diferentes projetos para entender como cada equipe resolve o mesmo problema.

Por exemplo: como diferentes projetos implementam Trusted Publishing, como controlam dependências de terceiros ou como protegem workflows executados por Pull Requests externos.

Esse exercício desenvolve uma habilidade importante: sair da posição de alguém que apenas corrige alertas e passar a compreender a arquitetura de segurança do processo de entrega.

Segurança de CI/CD exige conhecimento sobre GitHub Actions, shell, permissões, autenticação, dependências, infraestrutura e supply chain security.

É justamente por isso que estudar workflows de projetos maduros é tão valioso: eles oferecem exemplos concretos de decisões de engenharia, problemas reais e estratégias de mitigação que podem ser adaptadas a outros ambientes.

Conclusão

Scanners são instrumentos de diagnóstico, não substitutos do conhecimento técnico.

Executar um scanner e aplicar todas as correções sugeridas sem entender os findings pode gerar configurações desnecessárias, exceções mal justificadas e até novos problemas.

O caminho mais consistente é combinar análise automatizada, estudo da documentação, investigação técnica e comparação com implementações de projetos reconhecidos.

Estudar pipelines de bons projetos é uma forma de aprender com decisões de engenharia que já foram colocadas à prova.

Afinal, um pipeline seguro não é aquele que simplesmente passa em todas as verificações. É aquele cuja arquitetura foi compreendida, cujos riscos são conhecidos e cujos mecanismos de proteção foram implementados de maneira consciente.

Automated PR Reviews with Cline and NVIDIA NIM APIs

Tue, 06 Oct 2026 11:57:57 +0000

AI has been evolving at a breakneck pace ever since the first consumer-facing products landed. I've been updating my personal development workflow since day one, keeping my tools and habits aligned with each new wave of progress.

Over time I've worked with a long list of models and tools.

Models

ChatGPT
Claude
Gemini

Tools

Cursor
GitHub Copilot for VS Code
GitHub Copilot for Xcode
Xcode Coding Intelligence
Trae
VS Code plugins: Cline, Roo Code, …

…and the list keeps growing.

For the last year or so I've been developing with TRAE / Gemini on macOS, and both the IDE and the model served me well. But those tools and models come with two recurring pain points:

Third-party apps mean your data sits in someone else's database.
Subscription fees can add up fast.

The natural answer to both is local LLMs. I tested that route on my MacBook M1 Pro with LM Studio, pulling models locally and wiring them into VS Code / Xcode:

Gemma
Qwen

…and a few others.

The honest result: on my hardware, local models weren't strong enough to beat the cloud subscription experience.

Then, a few days ago, I discovered that NVIDIA is running open models on its own servers for free at build.nvidia.com. I immediately wanted to try my workflow against that service — first with the NVIDIA NIM Provider extension in VS Code, then side-by-side with Cline. The Cline + NVIDIA NIM combo turned out to be noticeably more stable, so that's what stuck.

I was about to undergo a major refactor on one of my projects TaxCalculator: turning the Flask/Python monolith (thousands of lines in index.html plus a tangled frontend) into a sliced, testable, readable, and maintainable structure.

That result genuinely made my day.

Just before merging the refactor PR, one more question popped into my head: Cline + NVIDIA NIM had carried me this far — could the same duo review my PRs automatically through GitHub Actions?

Spoiler: yes, it can. Here's the full story, including the bumps along the way.

Why Automated PR Review?

I'm already constantly reviewing AI-generated code during development and again at PR time. Adding a third pass — an automated PR review bot — is the obvious next step for both security and robustness, right? An LLM-based agent is especially good at catching:

Domain-specific rules (Clean Architecture, Decimal for money, no hardcoded secrets)
Edge cases / null-safety issues
Test coverage gaps
API & architecture inconsistencies

Cline CLI is ideal for this: it runs headless, integrates with gh, and supports any OpenAI-compatible API.

Architecture

PR opened → GitHub Actions workflow triggers
          → Diff fetch (1 API call, capped by context budget)
          → Cline CLI: read review rules + analyze diff
          → gh pr review --comment to leave inline feedback

Three files do the work:

File	Role
`AGENTS.md`	Universal review rules (same across every project: language, secrets, dependencies, naming, commits)
`.clinerules/taxcalculator.md`	Project-specific rules (Clean Arch boundaries, `Decimal`, zero-data-retention, mandatory Flask blueprints, `LoggerService`, `ConcurrencyService`)
`.github/workflows/cline-pr-review.yml`	CI workflow

Why two rule files? So I can copy AGENTS.md verbatim into other projects. Cline auto-loads anything inside .clinerules/ natively — no extra config needed.

Step-by-Step Setup

1. Add the secret

In the GitHub repo go to Settings → Secrets and variables → Actions and add:

NVIDIA_API_KEY = your key from build.nvidia.com

2. Write the workflow file

on:
  pull_request:
    types: [opened, ready_for_review, synchronize]

jobs:
  cline-review:
    runs-on: ubuntu-latest
    timeout-minutes: 25
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '24' }
      - run: npm install -g cline

      - name: Authenticate Cline with NVIDIA NIM
        env: { NVIDIA_API_KEY: ${{ secrets.NVIDIA_API_KEY }} }
        run: |
          cline auth --provider openai \
            --apikey "$NVIDIA_API_KEY" \
            --baseurl "https://integrate.api.nvidia.com/v1" \
            --modelid "minimaxai/minimax-m3"

The 6 Problems I Hit (and how I fixed them)

1. Node 20 deprecation

Error: Node.js 20 is deprecated... being forced to run on Node.js 24
Fix: node-version: '24' (Cline CLI also requires Node 22.15+ for TLS trust store).

2. `unknown option '--base-url'`

Error: cline CLI does not accept dashed flags for this option.
Fix: Drop the dash: --baseurl "https://integrate.api.nvidia.com/v1".

3. `auth quick setup requires --modelid`

Error: quick-setup mode forces you to pick a model.
Fix: Add --modelid "minimaxai/minimax-m3".

4. `429 Too Many Requests` (rate limit)

Problem: NVIDIA's free tier caps you at 40 requests per minute. Every time Cline reads a slice of the diff, that's one request to the LLM. A large diff made Cline fetch it in several chunks, passing the 40 limit in under a minute — as a result the API responded with HTTP 429 and stopped serving.

Fix — two layers:

(a) Diff pre-preparation in the workflow, not in Cline:
Fetch the full diff once, cap it by a budget derived from the model's context window, and derive the file list locally. Cline then just cats the prepared files — one read, one request.

- name: Prepare PR diff
  env:
    MODEL_CONTEXT_WINDOW: "128000"   # token limit of the model
    DIFF_BUDGET_RATIO: "0.7"         # share of context for the diff
    DIFF_TOKENS_PER_LINE: "3"        # avg token density of a unified diff
  run: |
    # Fetch the diff once. Each subsequent read by Cline would be another
    # LLM call, burning our 40 RPM budget.
    gh pr diff "$PR" > /tmp/diff_full.txt
    TOTAL_LINES=$(wc -l < /tmp/diff_full.txt)

    # Derive the line cap from the model's context window. This is NOT a
    # magic number — change MODEL_CONTEXT_WINDOW to retarget a different model.
    MAX_LINES=$(awk -v ctx="$MODEL_CONTEXT_WINDOW" -v ratio="$DIFF_BUDGET_RATIO" \
                   -v tpl="$DIFF_TOKENS_PER_LINE" \
                   'BEGIN { printf "%d", ctx * ratio / tpl }')

    # Truncate to the cap. Anything beyond is dropped with a GitHub Actions
    # warning annotation so reviewers see why.
    if [ "$TOTAL_LINES" -le "$MAX_LINES" ]; then
      cp /tmp/diff_full.txt /tmp/diff.txt
    else
      head -"$MAX_LINES" /tmp/diff_full.txt > /tmp/diff.txt
      echo "::warning::Diff truncated from $TOTAL_LINES to $MAX_LINES lines"
    fi

    # Build the file list locally from 'diff --git' headers — no extra API call.
    grep '^diff --git' /tmp/diff_full.txt | sed -E 's|^diff --git a/(.+) b/.*|\1|' \
      > /tmp/diff_summary.txt

(b) Strict prompt budget — max 5 tool calls, gh pr diff banned:
Without these rules, an LLM agent will happily re-fetch the diff, read extra files for "context", and burn through your rate budget. We tell Cline exactly what we want it to do, in what order, and how many steps it's allowed to take.

- Do NOT call 'gh pr diff' again.
- Make at most 5 tool calls total.
- Read /tmp/diff_summary.txt and /tmp/diff.txt via 'cat'.
- Post all review comments in ONE 'gh pr review --comment' call.

5. `unknown flag: --stat`

Error: gh pr diff --stat does not exist in this gh version (only --name-only and --patch).
What we wanted it for: the "X files changed, +Y −Z" summary you see on the PR page. We needed that list so Cline could see the affected files before reading the diff.
Fix: Extract the file list locally from the diff --git a/... b/... headers in the diff itself. No extra API call, just text processing:

grep '^diff --git' /tmp/diff_full.txt | sed -E 's|^diff --git a/(.+) b/.*|\1|'

6. Retries duplicate findings

Symptom: On a transient 429 or socket drop, naively adding || sleep 60 && retry seems safe. In practice it isn't — Cline is invoked as a fresh CLI process each time, so the retry restarts from scratch: re-reads the diff, re-reads context, and posts duplicate review comments on the same PR.
Fix: No retry. Run Cline once, fail loudly on failure. If a future change makes retries necessary, persist Cline's intermediate state to disk between attempts so a retry can resume.

# No retry — Cline must complete in one session.
cline --auto-approve true "$PROMPT" \
  || (echo '::error::Cline review failed'; exit 1)

How We Pick the Dynamic Line Limit

The cap is not a magic number. It's derived from three constants the workflow exposes as environment variables:

Variable	Default	Why
`MODEL_CONTEXT_WINDOW`	`128000`	Token limit of the model you call
`DIFF_BUDGET_RATIO`	`0.7`	Share of the context reserved for the diff
`DIFF_TOKENS_PER_LINE`	`3`	Average token density of a unified diff

The formula:

max_lines = context_window × diff_budget_ratio ÷ diff_tokens_per_line
         = 128_000 × 0.7 ÷ 3
         ≈ 29_866 lines

So a typical PR with fewer than ~30k diff lines is reviewed in full. Anything larger is truncated and the workflow emits a ::warning:: annotation explaining the cap.

Why not "unlimited"? Three real upper bounds apply, and any of them can break the run:

Model context window — the diff, system prompt, rules, and the agent's output all share one token budget. Overflow = truncated reasoning or broken output.
Workflow timeout — the job-level timeout-minutes caps the total runtime. A multi-hundred-thousand-line diff cannot finish reviewing inside the window.
Rate limit — free NVIDIA NIM caps at 40 RPM. A giant diff turns into many LLM calls if the agent reads it in pieces.

Trade-offs you can tune:

DIFF_BUDGET_RATIO = 0.9 → bigger diff, less room for Cline's reasoning/output.
DIFF_BUDGET_RATIO = 0.5 → smaller diff, larger safety margin.
timeout-minutes → increase for very large diffs, decrease for faster feedback.
Switch models → set MODEL_CONTEXT_WINDOW (e.g. 32000) and the cap recomputes automatically.

Result: A Real PR Review

On a real PR, the workflow produced output like this:

🚨 Critical: duplicate block in report_service._create_trades_from_lists, hard-coded strings, remember=True cookie leaking across sessions
⚠️ Important: privacy/data-retention violation (cvs_hash persisted server-side), missing integration tests under tests/unit/parsers/, architecture inconsistencies
✨ Nits: quote style inconsistency, NonJSON typo, multi-line logs

In other words: universal rules + project-specific rules + single-shot review + dynamic diff budget combined into a real, value-adding automated review running on a free tier.

Real Example: TaxCalculator Refactor (PR #13)

Here's an actual PR review generated by the workflow on my TaxCalculator project — a large refactor turning a Flask monolith into Clean Architecture boundaries.

PR Review — eraydiler/TaxCalculator#13

Overall the PR is a large refactor that improves structure (Clean Architecture boundaries, partials, JS modules, tests). However, several blocking issues need attention before merging.

🔴 Blocking — Privacy: zero-data-retention claim is violated

ARCHITECTURE.md (and README.md) explicitly promise "No user report data (CSV content, tax summary) is persisted on the server. All report data lives exclusively in the clients IndexedDB." The diff contradicts this:

src/models/report_task.py stores csv_content on the model:

self.csv_content: Optional[str] = task_data.get("csv_content")
...
"csv_content": self.csv_content,

src/repositories/mongo_task_repository.py writes csv_content to MongoDB:

if csv_content is not None:
    update_data["csv_content"] = csv_content

src/blueprints/auth.py (download_csv) reads task.csv_content from MongoDB and serves it.

The project-specific rule Privacy: Server must NOT persist CSV report content or tax summaries is being broken by this change. Either:

Remove csv_content from ReportTask and persist only csv_hash (the documented design), and make the client responsible for retaining the CSV in IndexedDB for re-download — or —
Update ARCHITECTURE.md / README.md to reflect the actual policy, and get explicit sign-off, since this is a documented user-facing privacy guarantee.

🟡 Logic / Security

src/blueprints/auth.py: the upload endpoint computes csv_hash for integrity but never compares the stored hash against a client-supplied hash on download — the integrity check described in ARCHITECTURE.md is one-directional only. If you keep csv_content in Mongo, at least verify hash equality before serving.
The webhook signature path uses X-Signature header; confirm this matches Lemon Squeezy's actual header name (X-Signature is correct for Lemon Squeezy — OK, but worth a comment).
tests/unit/test_webhook_idempotency.py patches src.app.payment_service.user_repository but the production code accesses the repo via the service, not the module-level attribute. Verify the patch target; otherwise this test passes without exercising the real path.

🟡 Tests

New tests added (good), but no unit test exists for the refactored mongo_task_repository create_task_metadata / update_task_status paths. Add coverage under tests/unit/ for both the success path and the privacy rule (assert that no csv_content is written when the zero-retention policy is enforced).
The download-race-condition test should also assert that csv_content is never written by the server, to lock in the privacy guarantee.

🟢 Minor / Style

tests/integration/test_end_to_end.py still contains print(...) debug noise (print("\nRow differences found:") etc.). Replace with LoggerService per the logging rule.
src/blueprints/auth.py returns {"error": "Geçersiz dosya formatı..."} — user-facing strings must be English unless localization is added; this is Turkish. Same applies to any other tr-string errors in the diff.
Commit messages are clean and descriptive — good.

✅ Looks good

Decimal is used consistently for monetary values (no float introduced for tax/money).
Blueprints live under src/blueprints/, not inline in app.py.
ConcurrencyService is used for parallel work.
LoggerService is used for errors/info.
JS is split into focused ES modules with proper single-responsibility boundaries.

Please address the Blocking privacy item first — it directly violates a documented user-facing promise and a project-specific review rule.

Lessons Learned

LLM agents are not cheap — even 40 RPM is tight, careful budgeting is essential.
CLI flags drift across versions — always check --help before writing the workflow.
Batch in the workflow, not in the agent — pre-preparation saves API calls.
Don't retry blindly — a fresh Cline process restarts from scratch and duplicates findings.
Keep universal rules separate from project-specific rules — reusable vs portable.
Derive magic numbers from real constraints — context window, timeout, rate limit — instead of guessing.
Real PR reviews catch real problems — the privacy violation in TaxCalculator#13 would have been missed by manual review alone.

Who Can Change Your npm Release Tags?

Thu, 01 Oct 2026 11:37:54 +0000

Who Should Be Allowed to Change Your npm Release Tags?

Your CI/CD pipeline may already be able to publish an npm package.

But here’s the more important question:

Should every workflow that can publish also be allowed to change latest, next, or beta tags?

GitHub’s recent npm trusted publishing update makes this separation much clearer.

Workflows can now receive explicit permission to manage npm distribution tags using short-lived OIDC credentials instead of keeping long-lived automation tokens around.

Why this matters

Release tags can directly affect which version users install.

Changing:

latest
next
beta

may look like a small metadata change, but in practice it can influence production adoption, prerelease testing, and package distribution.

That means tag management deserves its own permission boundary.

What development teams should review

Before changing anything in production, I’d check these first:

Which workflow actually needs to manage release tags?
Does that workflow really need broader publishing permissions too?
Can the operation be handled through OIDC-based trusted publishing?
Have you tested tag updates before removing existing credentials?
Are old automation tokens still required anywhere else?

A good principle here is:

Give automation only the permissions it actually needs.

The tag-management permission is off by default, which is a sensible security choice.

And importantly, moving to short-lived credentials does not remove the need for:

release testing
permission reviews
CI/CD controls
rollback planning
software supply-chain security

Discussion

I think this is a good example of where least privilege becomes practical, not theoretical.

Publishing a package and deciding which release becomes latest are related actions—but they are not necessarily the same responsibility.

How are you handling this in your npm workflows today?

Do you keep publishing and tag management in one workflow, or would you separate them?

#NPM #GitHubActions #DevSecOps #CICD #OIDC #SoftwareEngineering #DevOps #SoftwareSupplyChain #PackageManagement #OpenSource #DeveloperTools #Automation #NodeJS #WaqasAhmad

# The Revolution in Protocol Security: How It Actually Gets Used

Thu, 20 Aug 2026 07:46:14 +0000

A follow-up. The previous article described what we are building. This one describes how it works in practice - and why the shift from academic tool to industrial platform matters.

In a previous article, I described the architecture of a protocol analyzer we are building: automatic repair, sixteen attacker models, GNN-guided search, modular crate design. That was the "what." This article is the "how" - how this tool gets used, what it changes in practice, and why we believe it represents a shift from laboratory instrument to industrial platform.

The problem with existing tools is not only capability - it is also access

ProVerif and Tamarin are remarkable achievements in formal methods. They are also laboratory instruments by design. You install them on a research machine, write a model in their DSL, run analysis in a terminal, read the output. This workflow is fine for a PhD student. It does not work for a security engineer at a company that ships TLS implementations.

The gap concerns where these tools live in the development lifecycle, not what they can prove. Existing tools sit outside CI pipelines, outside IDEs, outside deployment workflows. They are consulted - if at all - after a protocol is designed, before it ships. Rarely during development, rarely after deployment.

We are building something that lives inside the lifecycle.

CI/CD integration: verify on every commit

The analyzer ships as a GitHub Action. Every time a protocol description changes - a new message flow, a modified key exchange, an added authentication step - the analyzer runs automatically. It checks whether the change introduces a vulnerability. If it does, the action fails with a concrete attack trace and a proposed fix.

This is not a theoretical capability. The action is designed to run in minutes on standard CI hardware, not hours on a research cluster. The performance targets we described in the previous article - 10x to 50x speedup, sub-ten-minute analysis for real-world protocols - exist to make this practical. A tool that takes six hours to analyze a protocol cannot run in CI. One that takes six minutes can.

Beyond GitHub Actions, the analyzer provides a CLI that integrates with any CI system - GitLab CI, Jenkins, Buildkite. The output is machine-readable: SARIF for security scanners, JSON for custom pipelines, JUnit XML for test reporting. Protocol verification becomes another test suite in the pipeline.

IDE integration: find vulnerabilities while you write

The analyzer ships a Language Server Protocol (LSP) implementation. In a VS Code editor, this means: syntax highlighting for the protocol DSL, inline error reporting as you type, hover documentation for security properties, and one-click analysis from the editor.

The experience is analogous to writing Rust with rust-analyzer: the tool understands what you are writing and gives feedback in real time. When you define a key exchange step, the analyzer checks whether the key material is properly authenticated. When you add a new message, it checks whether the freshness guarantees hold. The vulnerability is flagged before you commit the code - not after.

Real-time analysis: the daemon and the sniffer

This is where the tool stops being a verifier and becomes a platform.

The analyzer runs as a background daemon with a gRPC API. Any service in the infrastructure can send a protocol description and receive analysis results. But the daemon does more than wait for requests - it listens to live traffic.

The sniffer module captures network traffic (PCAP), reconstructs protocol sessions from packet streams, and feeds them to the symbolic engine in real time. When a TLS handshake happens on the network, the analyzer checks whether that handshake - with its specific cipher suite, extensions, and parameters - satisfies the security properties. When an unusual pattern appears - a repeated nonce, an unexpected message order, a downgrade attempt - it flags the anomaly.

This is live verification - analysis that runs while the protocol is executing, not after the fact.

The real-time constraint changes the engineering at its core. Traditional protocol analysis explores the full state space - every possible interleaving, every attacker action. That takes hours. Real-time analysis uses a bounded model: explore the state space up to depth N, report what you find, continue monitoring. The GNN-guided search from our previous article is critical here - it prioritizes the most promising exploration paths, finding attacks faster in bounded time.

Web interface: collaboration, not just output

The analyzer ships a web UI. This is a requirement for adoption, not a luxury.

Security review is a collaborative process. An analyst finds an attack, a protocol designer evaluates the proposed fix, a manager decides whether the risk is acceptable. In existing tools, this workflow happens outside the tool: screenshots in Slack, traces in emails, decisions in meetings.

The web UI makes the analysis itself collaborative. Attack graphs are rendered in 3D - navigable, zoomable, inspectable. Repair proposals are presented side-by-side with the original protocol, with the differences highlighted. Reviewers can comment, approve, or reject fixes. The entire security review happens inside the platform.

Converters: meeting people where they are

The analyzer accepts input from ProVerif, Tamarin, Scyther, Avispa, CryptoVerif, and Maude descriptions. This is an adoption strategy, not a convenience feature.

Thousands of protocols are already modeled in these languages. Researchers and engineers who have invested years in ProVerif models should not have to rewrite them. They import their existing description, run the analyzer, and get the same output plus repair proposals plus real-time monitoring plus CI integration.

The converters are imperfect - each source language has constructs that do not map cleanly. But they handle the common case well enough to lower the barrier from "I should try this tool" to "I just tried this tool."

Platform, not tool

Let us be explicit about what we are building. A tool does one thing from the command line. A platform integrates into workflows, provides APIs, runs continuously, and collaborates with other systems.

The protocol analyzer we are building has:

A CLI for direct use and scripting
A GitHub Action for CI/CD
An LSP server for IDE integration
A gRPC API for programmatic access
A daemon for continuous monitoring
A sniffer for real-time traffic analysis
A web UI for collaborative review
WASM bindings for browser-based playground
Converters from five existing tools

This is a platform. The symbolic analysis core - the part described in the previous article - is the engine. Everything else is the interface between that engine and the world where protocols are built, deployed, and attacked.

The revolution is practical, not technical

The technical contributions matter: automatic repair, GNN-guided search, incremental closure, sixteen attacker models. But the reason they matter is that they enable a new capability - protocol verification that runs in CI, in your IDE, on your network, in real time.

ProVerif and Tamarin proved that symbolic protocol analysis is possible. We are trying to prove that it is practical - practical enough to run on every commit, practical enough to catch vulnerabilities while you type, practical enough to monitor live traffic.

That is the shift: from laboratory instrument to industrial platform. From "analyze after design" to "verify during development and after deployment." From a tool that finds attacks to a platform that finds them, fixes them, and watches for them.

Status

The CI/CD action, the LSP server, the daemon, and the sniffer are in active development. The web UI has working prototypes. The converters handle common cases. The core engine - described in the previous article - is functional and stable.

This project is under active development. The platform described here is being built, not shipped. But the direction is clear, and the architecture supports it.

This project is under active development. This article describes the planned platform capabilities of a tool still being built. The previous article covers the core engine architecture; this one covers the interfaces between that engine and the development lifecycle.

Follow the project: github.com/Sup4ikX - a preview release will be published there as soon as the first production version is ready.

Automatically update GitHub Action versions

Mon, 29 Jun 2026 14:49:47 +0000

You don't notice your GitHub Actions versions until you start getting warnings about things like "Node 20 is no longer supported". When you think about it, GitHub Actions are yet another dependency that needs to be kept up to date and present supply chain risks.

Get Dependabot to do the work

The good news is, you can get Dependabot to keep your GitHub Actions up to date for you. You can add instructions for this to your .github/dependabot.yml:

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

In my case I already had configuration for my npm dependencies:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

But it's trivial to add multiple updates to the same file:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Automatic pull requests

When you first commit this file, you'll notice pull requests start appearing for your review.

- name: Setup pnpm cache
    uses: actions/cache@v4 (-)
    uses: actions/cache@v5 (+)

This is a simple example of how you can use Dependabot to keep your GitHub Actions up to date. You can find more information about Dependabot in the GitHub documentation.

Setting GitHub as a trusted publisher for npm

Tue, 26 May 2026 06:29:10 +0000

So, stuff happened and npm has been updated to reduce the volume of stuff happening. In a world of SBOMs, SLSA, and supply chain attacks, it's time to get serious about publishing packages. In this case, that means using the new Trusted Publisher feature to connect GitHub (or GitLab) to npm.

Set the trusted publisher on npm

Sign into npm
Select the package you want to set up, for example astro-accelerator-utils
Click Settings
In the Trusted Publishers section, select your provider, in my case it's GitHub
Enter you repository information:
- Organization or user name, for example Steve-Fenton
- Repository name, for example astro-accelerator-utils
- The result should be that Steve-Fenton/astro-accelerator-utils matches your repo in GitHub
Provide the workflow file name
- This should match the workflow that will publish the package, in my case build-astro.yml
- The file must be in .github/workflows/
Click Set up connection

If you use environments, you can optionally limit publishing by environment.

Check you GitHub Action

In your permissions section, you need to allow id-token to be written.

permissions:
    id-token: write

You can then use the npm publish step in your workflow.

I conditionally publish based on the version number, so I only publish when the version number changes.

- name: Publish if version has been updated
    env:
        NPM_AUTH_TOKEN: ${{ secrets.NPM_AUTH_TOKEN }}
    run: |
        PACKAGE_NAME=$(node -p "require('./package.json').name")
        LOCAL_VERSION=$(node -p "require('./package.json').version")
        REMOTE_VERSION=$(npm view $PACKAGE_NAME version || echo "0.0.0")

        if [ "$LOCAL_VERSION" != "$REMOTE_VERSION" ] && [ "$(printf '%s\n%s' "$REMOTE_VERSION" "$LOCAL_VERSION" | sort -V | tail -n1)" = "$LOCAL_VERSION" ]; then
        echo "Local version $LOCAL_VERSION is higher than remote version $REMOTE_VERSION. Publishing..."
        echo "//registry.npmjs.org/:_authToken=$NPM_AUTH_TOKEN" > ~/.npmrc
        npm publish --access public
        else
        echo "Version $LOCAL_VERSION is not newer than $REMOTE_VERSION. Skipping publish."
        fi

This is a more secure way to publish npm packages, but it's also easier because you don't need to keep updating tokens and secrets.

Stop Rewriting CI/CD: Reusable GitHub Actions for Maven Projects

Tue, 28 Apr 2026 01:40:16 +0000

Stop Rewriting CI/CD Pipelines for Every Maven Project

If you’ve worked on multiple Java projects, you’ve probably run into this:

Every repository has its own version of a CI/CD pipeline.

Slightly different YAML.
Slightly different setup steps.
Slightly different ways of doing the same thing.

And somehow… none of them are reusable.

The Real Problem

It’s not that CI/CD is hard.

It’s that it’s repetitive.

You end up doing the same things over and over:

Set up Java
Cache Maven dependencies
Run tests
Build artifacts
Handle versioning
Publish or release

Then copy that workflow into another repo…
…and tweak it just enough to break consistency.

This is exactly the kind of problem automation should solve — yet we keep duplicating it.

A Different Approach

Instead of treating each pipeline as a one-off YAML file, I started thinking:

What if CI/CD steps were modular and reusable — just like code?

That’s where NERV-Actions came from.

https://github.com/your-repo-link

What NERV-Actions Is

NERV-Actions is a collection of reusable GitHub Actions designed for Maven-based projects.

The idea is simple:

Break CI/CD into small, composable actions
Reuse them across repositories
Keep pipelines consistent without rewriting everything

Instead of this:

# repeated in every repo
- uses: actions/setup-java@v4
- run: mvn clean install

You plug in reusable building blocks that already handle those concerns.

Why This Matters

Reusable workflows aren’t just about convenience — they solve real scaling problems.

When you define things once and reuse them:

You reduce duplication
You avoid inconsistencies across repos
You make updates easier (change once, apply everywhere)
You spend less time debugging YAML

Design Philosophy

I didn’t try to build a one-size-fits-all pipeline.

Instead, NERV-Actions focuses on:

Composable units → mix only what you need
Sensible defaults → minimal setup required
Consistency → same patterns across projects
Extensibility → override when necessary

It’s closer to building blocks than a framework.

Example Use Case

For a typical Maven project, your pipeline usually boils down to:

Run tests
Build artifacts
Publish packages
Create releases

With reusable actions, you don’t redefine these steps every time — you just assemble them.

Why Not Just Copy-Paste?

Because copy-paste doesn’t scale.

It works for 2–3 repos.
It breaks down at 10+.

Suddenly:

Fixes don’t propagate
Pipelines drift
Debugging becomes inconsistent

Reusable actions solve that by centralizing the logic.

Still Evolving

This isn’t meant to be a perfect CI/CD solution.

It’s a practical attempt to reduce the friction I kept running into across projects.

If you’re dealing with the same repetition in GitHub Actions, this might be useful:

https://github.com/czetsuyatech/nerv-actions

Curious About Your Setup

Are you:

copying workflows between repos?
using reusable workflows heavily?
or building your own internal action libraries?

Would be interesting to hear how others are handling this.

Weather Service Project (Part 1): Building the Data Collector (Python, GitHub Actions or Netlify)

Tue, 20 Jan 2026 06:48:57 +0000

As I mentioned in a previous post, one of my goals with Datalaria is to get my hands dirty with projects that allow me to learn and connect different technologies in the data world. Today, we begin a series dedicated to one of those projects: the creation of a complete global weather service, from data collection to visualization and prediction, all serverless and using free tools.

In this first installment, we will focus on the heart of the system: the backend data collector. We'll see how to build a "robot" that works for us 24/7, connecting to an external API, saving structured information, and doing all this automatically and for free. Let's dive in!

The First Step: Talking to the OpenWeatherMap API

Every weather service needs a data source. I chose OpenWeatherMap for its popularity and generous free plan. The initial process is straightforward:

Register: Create an account on their website.
Get the API Key: Generate a unique key that will identify us in each call. It's like our "key" to access their data.
Store the Key: Never directly in the code! We'll discuss this further below.

With the key in hand (or almost!), I wrote a first test_clima.py script to test the connection using Python's fantastic requests library:

import requests

API_KEY = "YOUR_API_KEY_HERE" # Temporarily! We'll use Secrets later
CITY = "Madrid"
URL = f"[https://api.openweathermap.org/data/2.5/weather?q=](https://api.openweathermap.org/data/2.5/weather?q=){CITY}&appid={API_KEY}&units=metric&lang=es"

try:
    response = requests.get(URL)
    response.raise_for_status() # Raises an exception for HTTP errors (4xx or 5xx)
    data = response.json()
    print(f"Temperature in {CITY}: {data['main']['temp']}°C")
except requests.exceptions.RequestException as e:
    print(f"Error connecting to the API: {e}")
except KeyError as e:
    print(f"Unexpected API response, key missing: {e}")

First Obstacle Overcome (with Patience): When I first ran it, I got a 401 Unauthorized error! It turns out that OpenWeatherMap API Keys can take a few hours to activate after being generated. The lesson: sometimes, the solution is simply to wait. ⏳

The "Database": Why CSV and Not SQL?

With data flowing, I needed to store it. I could have set up an SQL database (PostgreSQL, MySQL...), but that would involve complexity, a server (cost), and for this project, it was overkill.

I opted for radical simplicity: CSV (Comma Separated Values) files.

Advantages: Easy to read and write with Python, perfectly versionable with Git (we can track changes), and sufficient for the initial data volume we'd be handling.
Key Logic: I needed to append a new row to each city's file daily, but only write the header (date_time, city, temperature_c, etc.) the first time. Python's native csv library and os.path.exists make this trivial:

import csv
import os
from datetime import datetime

# ... (code to fetch API data for a city) ...

now = datetime.now().strftime('%Y-%m-%d %H:%M:%S')
data_row = [now, city, temperature, ...] # List with the data
header = ['date_time', 'city', 'temperature_c', ...] # List with column names
file_name = f"data/{city}.csv" # We'll create a 'data' folder

# Ensure the 'data' folder exists
os.makedirs(os.path.dirname(file_name), exist_ok=True)

is_new_file = not os.path.exists(file_name)

try:
    with open(file_name, mode='a', newline='', encoding='utf-8') as f:
        writer = csv.writer(f)
        if is_new_file:
            writer.writerow(header) # Write header ONLY if new file
        writer.writerow(data_row) # Append the new data row
    print(f"Data saved for {city}")
except IOError as e:
    print(f"Error writing to {file_name}: {e}")

The Automation Robot: GitHub Actions to the Rescue

Here comes the magic: how to make this script run daily without having a server constantly on? The answer is GitHub Actions, the automation engine integrated into GitHub. It's like having a small robot working for us for free.

Security First: Never Upload Your API Key!

The biggest mistake would be to upload registrar_clima.py with the API_KEY written directly in the code. Anyone could see it on GitHub.

Solution: Use GitHub's Repository Secrets.
1. Go to Settings > Secrets and variables > Actions in your GitHub repository.
2. Create a new secret named OPENWEATHER_API_KEY and paste your key there.
3. In your Python script, read the key securely using os.environ.get("OPENWEATHER_API_KEY").

The Robot's Brain: The `.github/workflows/update-weather.yml` File

This YAML file tells GitHub Actions what to do and when:

name: Daily Weather Data Update

on:
  workflow_dispatch: # Allows manual triggering from GitHub
  push:
    branches: [ main ] # Triggers if changes are pushed to the main branch
  schedule:
    - cron: '0 6 * * *' # The key: triggers daily at 06:00 UTC

jobs:
  update_data:
    runs-on: ubuntu-latest # Use a free Linux virtual machine
    steps:
      - name: Checkout repository code
        uses: actions/checkout@v4 # Downloads our code

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.10' # Or your preferred version

      - name: Install necessary dependencies
        run: pip install -r requirements.txt # Reads requirements.txt and installs requests, etc.

      - name: Execute data collection script
        run: python registrar_clima.py # Our main script!
        env:
          OPENWEATHER_API_KEY: ${{ secrets.OPENWEATHER_API_KEY }} # Securely injects the secret

      - name: Save new data to repository (Commit & Push)
        run: |
          git config user.name 'github-actions[bot]' # Identifies the 'bot'
          git config user.email 'github-actions[bot]@users.noreply.github.com'
          git add data/*.csv # Adds ONLY the modified CSV files in the 'data' folder
          # Check if there are changes before committing to avoid empty commits
          git diff --staged --quiet || git commit -m "Automated weather data update "
          git push # Pushes changes to the repository
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # Automatic token to allow the push

This last step is crucial! The Action itself acts as a user, performing git add, git commit, and git push of the CSV files that the Python script has just modified. This way, the updated data is saved in our repository every day.

The Serverless Alternative: Deployment and Automation with Netlify

While GitHub Actions is a fantastic automation tool, for this project I decided to explore an alternative even more integrated with the "serverless" concept: Netlify. Netlify not only allows us to deploy our static frontend (like GitHub Pages) but also offers serverless functions and, crucially for our backend, scheduled functions (or Cron Jobs).

Deploying the Static Frontend with Netlify

Connect Your Repository: The process is incredibly simple. Log in to Netlify, click "Add new site," and select "Import an existing project." Connect with your GitHub account and choose your Weather Service project repository.
Basic Configuration: Netlify will automatically detect your project. Ensure that the "Build command" is empty (as it's a static site with no build process) and that the "Publish directory" is the root of your repository (./).
Continuous Deployment: Netlify will automatically configure continuous deployment. Every time you git push to your main branch (or whichever branch you've configured), Netlify will rebuild and deploy your site.

Automating the Backend with Netlify Functions (and Cron Jobs)

This is where Netlify Serverless Functions shine for our data collector. Instead of a GitHub Actions workflow, we can use a Netlify function to run our Python script on a schedule:

Project Structure: Create a netlify/functions/ folder at the root of your project. Inside, you can have a Python file like collect_weather.py.
Dependency Management: You'll need a requirements.txt file at the root of your project for Netlify to install Python dependencies (requests, pandas, scikit-learn).

netlify.toml Configuration: This file at your project's root is crucial for defining your functions and their schedules:

[build]
  publish = "." # Directory where your index.html is located
  command = "" # No build command needed for a static site

[functions]
  directory = "netlify/functions" # Where your functions are located
  node_bundler = "esbuild" # For JS/TS functions. Netlify will detect Python.

[[edge_functions]] # For scheduling a function (requires Netlify Edge Functions)
  function = "collect_weather" # The name of your function (without the .py extension)
  path = "/.netlify/functions/collect_weather" # The function path (can be different)
  schedule = "@daily" # Or use a cron string like "0 6 * * *"

The Python Function (netlify/functions/collect_weather.py): This function will encapsulate the logic of your registrar_clima.py. Netlify will execute it in a Python environment.

# netlify/functions/collect_weather.py
import json
import requests
import os
import time
from datetime import datetime
import csv

# ... (all your registrar_clima.py script code goes here) ...

def handler(event, context):
    # The main call to your data collection logic would go here
    # This is a simplified example
    try:
        # Your logic to fetch and save data, generate CSVs/JSONs
            
        # For this project, the GitHub Actions approach for the backend
        # that directly commits to the repo is still simpler
        # for CSV storage. Netlify would be ideal for the frontend
        # and functions for real-time APIs or lightweight predictions.

        print("Netlify function for weather collection executed.")
        return {
            "statusCode": 200,
            "body": json.dumps({"message": "Backend logic would run here."}),
        }
    except Exception as e:
        return {
            "statusCode": 500,
            "body": json.dumps({"error": str(e)}),
        }

Environment Variables in Netlify: For the OPENWEATHER_API_KEY, go to Site settings > Build & deploy > Environment variables and add your key there.

Important Consideration: For the Netlify function to persist changes directly to your GitHub repository (like committing the CSVs), you would need a more advanced setup. To maintain simplicity and direct storage in the Git repository with automatic CSV commits, the GitHub Actions solution remains the most straightforward and efficient for the data collector backend in this specific case.

The Scaling Problem (and the Necessary Architectural Pivot)

My initial idea was to monitor about 1000 cities and store everything in a single weather_data.csv file. I did a quick calculation: 1000 cities ~200 bytes/day 365 days * 3 years... over 200 MB!

Why is this a problem? Because the frontend (our dashboard, which we'll see in the next post) runs in the user's browser. It would have to download that entire 200 MB just to display the graph for one city. Totally unacceptable in terms of performance.

The Architectural Solution: Switch to a "one file per entity" strategy.

We create a data/ folder.
The registrar_clima.py script now generates (or appends data to) one CSV file per city: data/Madrid.csv, data/Leon.csv, data/Tokyo.csv, etc.

This way, when the user wants to see the weather for Leon, the frontend will only download the data/Leon.csv file, which will be just a few kilobytes. Instant loading! ✨

Second Scaling Obstacle (API Limits): OpenWeatherMap, in its free plan, allows about 60 calls per minute. My loop to get data for 155 cities (my current list) would make these calls too quickly.

Vital Solution: Add import time at the beginning of the Python script and time.sleep(1.1) at the end of the for city in cities: loop. This introduces a pause of slightly more than 1 second between each API call, ensuring we stay below the limit and avoid being blocked.

Conclusion (Part 1)

We've got the foundation! We've built a robust and automated system that:

Connects to an external API securely.
Processes and stores historical data for multiple entities (cities).
Runs daily, at no cost, thanks to GitHub Actions.
Is designed to scale efficiently.

In the next post, we'll put on our frontend developer hats and build the interactive dashboard that will allow any user to explore this data with dynamic graphs. Don't miss it!

References and Links of Interest:

Complete Web Service: See the live project in action here: https://datalaria.com/apps/weather/
Project GitHub Repository: Explore the source code and project structure: https://github.com/Dalaez/app_weather
OpenWeatherMap: Weather API documentation: https://openweathermap.org/api
Python Requests: Documentation for the HTTP requests library: https://requests.readthedocs.io/en/master/
GitHub Actions: Official GitHub Actions guide: https://docs.github.com/en/actions
Netlify: Official Netlify website: https://www.netlify.com/

Hello World to GitHub Actions: Your First Automated Workflow

Thu, 25 Dec 2025 06:23:00 +0000

Hey there! So you're building a React app with TypeScript and Vite, and you keep hearing people talk about CI/CD and GitHub Actions. What's all the fuss about? Let me break it down for you in plain English.

What's GitHub Actions Anyway?

Think of GitHub Actions as your automation buddy that lives in your GitHub repo. You tell it "hey, whenever I push code, run my tests and make sure nothing broke," and it just... does it. Automatically. While you grab coffee(or chai) or work on something else.

Pretty cool, right? Here's what makes it awesome:

It's automatic - No more remembering to run tests before you push. Your automation buddy handles it.

It's consistent - Everyone's code gets tested the same way, every single time. No more "but it works on my machine!"

It's free - GitHub gives you a generous amount of free minutes every month. For most personal projects, you won't pay a dime.

It's built-in - Everything happens right in GitHub. No need to sign up for yet another service.

The Basics (Don't Worry, It's Simple!)

Before we jump into code, let's get familiar with a few terms:

Workflows are like recipes. They're files that tell GitHub Actions what to do. You write them in a language called YAML (it's just a fancy text format, nothing scary).

Events are triggers. "When someone pushes code" or "when someone opens a pull request" - these are events that kick off your workflow.

Jobs are the big tasks in your recipe. Like "build the app" or "run tests." Each job runs on its own fresh computer in the cloud.

Steps are the small tasks inside a job. Things like "install dependencies" or "run the linter."

Actions are pre-made shortcuts. Instead of writing commands to set up Node.js from scratch, you can use an action someone else already made. It's like using a package from npm, but for your workflows.

Let's Build Your First Workflow!

Alright, enough theory. Let's make something real. We're going to create a workflow that checks your code every time you push or open a pull request.

Creating the File

First, make a new folder in your project: .github/workflows/. Yes, it starts with a dot - that's on purpose!

Inside that folder, create a file called ci.yml. Here's what goes in it:

name: CI Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main, develop ]

permissions:
  contents: read

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      
      - name: Install dependencies
        run: npm ci
      
      - name: Run linter
        run: npm run lint
      
      - name: Type check
        run: npm run type-check
      
      - name: Build project
        run: npm run build
      
      - name: Run tests
        run: npm test

What's All This Mean?

Let me walk you through it:

name: CI Pipeline - Just a friendly name for your workflow. You'll see it in the GitHub interface.

on: - This is where you say "run this when..." In our case, we're saying "run when someone pushes to main or develop, OR when someone opens a pull request."

permissions: - This is important! We're telling GitHub "hey, this workflow only needs permission to read our code, nothing else." It's like giving someone a library card instead of the keys to the building. Good security practice!

jobs: - Here's where the actual work happens. We've got one job called "build-and-test."

runs-on: ubuntu-latest - This means "run on a computer with Ubuntu Linux." GitHub provides this for free!

steps: - These are the actual commands that run, one after another:

First, we grab the code
Then we install Node.js
Install our dependencies
Run the linter to check code style
Check for TypeScript errors
Build the project
Run our tests

Setting Up Your package.json

Your package.json needs to have these scripts for the workflow to work:

{
  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "lint": "eslint . --ext ts,tsx --report-unused-disable-directives --max-warnings 0",
    "type-check": "tsc --noEmit",
    "test": "vitest run",
    "preview": "vite preview"
  }
}

Don't have ESLint or Vitest set up yet? No worries - you can skip those steps in your workflow for now and add them later.

Want to Deploy Automatically Too?

Once your tests pass, you might want to deploy your app. Here's a workflow that deploys to GitHub Pages:

name: Deploy to GitHub Pages

on:
  push:
    branches: [ main ]

permissions:
  contents: read
  pages: write
  id-token: write

jobs:
  build:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      
      - name: Install dependencies
        run: npm ci
      
      - name: Build project
        run: npm run build
      
      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: ./dist
  
  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

This one's a bit different - it has TWO jobs. The second job (deploy) waits for the first one (build) to finish successfully. That needs: build line is what makes that happen.

Making It Faster with Caching

Want your workflows to run faster? Good news - the actions/setup-node@v4 action we're using already caches your npm packages when you add cache: 'npm'. That means the second time your workflow runs, it won't have to download all your dependencies again. Pretty smart!

Keeping Secrets... Secret

Sometimes you need API keys or passwords in your builds. DON'T put them directly in your workflow file - that's like posting your house keys on Instagram.

Instead, use GitHub's secrets feature:

Go to your repo's Settings
Click on "Secrets and variables" then "Actions"
Click "New repository secret"
Add your secret (like VITE_API_KEY)

Then use it in your workflow like this:

- name: Build project
  run: npm run build
  env:
    VITE_API_KEY: ${{ secrets.VITE_API_KEY }}

GitHub will hide it in the logs automatically. Nice!

Checking If It's Working

After you push your workflow file to GitHub:

Click the "Actions" tab in your repo
You'll see your workflow running (or done running)
Click on it to see all the details
If something breaks, click on the red X to see what went wrong

The logs tell you EXACTLY what happened at each step. It's super helpful for debugging.

Understanding Workflow Permissions

Quick important thing - see that permissions block we added? That's like setting up proper door locks for your house.

By default, workflows might have way more permissions than they need. We're being explicit and saying "this workflow only needs to READ the code" with contents: read. If later you need to do something like comment on pull requests, you'd add pull-requests: write.

It's just a good habit to be clear about what your workflow can and can't do. Your future self (and your team) will thank you!

Some Quick Tips

Here are a few things that'll make your life easier:

Set permissions explicitly - Like we just talked about, always add that permissions block. Start with contents: read and only add more when you need it.

Use version tags - Notice how we use @v4 in our actions? That's better than using @main because it won't suddenly change on you. Your workflows stay stable.

Use npm ci not npm install - In automated environments, npm ci is faster and more reliable. It's designed specifically for CI/CD.

Run jobs in parallel - If you have multiple jobs that don't depend on each other, they'll run at the same time. Saves time!

Add a badge to your README - In the Actions tab, you can grab a badge that shows if your build is passing. It looks professional!

Test different Node versions - You can use something called a matrix to test on Node 18, 20, and 21 all at once. Here's how:

strategy:
  matrix:
    node-version: [18, 20, 21]

Protect your main branch - In your repo settings, you can require that all checks pass before merging. No more broken builds!

Separate your workflows - Keep your testing workflow separate from your deployment workflow. Makes things easier to understand and manage.

When Things Go Wrong

Don't panic! Here are common issues and fixes:

Workflow not running? - Check that your YAML file is in .github/workflows/ and that you don't have any syntax errors. YAML is picky about spaces and indentation.

Works on your computer but not in CI? - Make sure all your dependencies are listed in package.json. Also check that you're not relying on environment variables that only exist on your machine.

Running out of build minutes? - Public repos get unlimited minutes! Private repos have limits. Check your usage in Settings → Billing.

What's Next?

You now know the basics! Here are some cool things to explore when you're ready:

Browse the GitHub Marketplace for actions other people have made
Set up notifications to Slack or Discord when builds fail
Add code coverage reporting
Create custom actions for your specific needs
Try matrix builds to test across multiple environments

The key is to start simple - get your basic testing pipeline working - then add more features as you need them. Don't try to do everything at once!

Wrapping Up

GitHub Actions might seem a bit intimidating at first, but once you get the hang of it, you'll wonder how you lived without it. No more forgetting to run tests. No more "oops, I broke main." Just push your code and let your automation buddy do its thing.

Start with the simple CI workflow we built together, make sure it works, and then gradually add more automation as you get comfortable. Before you know it, you'll be the GitHub Actions expert on your team!

Happy automating!

CI/CD That Ships Itself: Our GitHub Actions Blueprint

Tue, 09 Dec 2025 12:06:26 +0000

CI/CD That Ships Itself: Our GitHub Actions Blueprint

(Pocket Portfolio — 12 Weeks of Shipping)

Fast releases are only useful if they are consistent and safe.
This post breaks down Pocket Portfolio’s CI/CD pipeline on GitHub Actions: how we lint, type-check, test against Firebase emulators, run Playwright smoke tests, and then canary-deploy to the Edge.

The goal is simple: every commit proves it can ship itself.

Pipeline Overview

Stages executed per pull request and on main:

1) Lint and TypeCheck
2) Build with reproducible caching
3) Firebase emulator tests (unit and integration)
4) Playwright UI smoke tests
5) Artifact capture (build, coverage, screenshots)
6) Canary deploy to next.pocketportfolio.app with manual approval
7) Post-deploy health checks and auto-rollback

We use:

GitHub Actions matrix to cover Node versions and Next.js runtime modes
Project-level concurrency to avoid clobbering environments
Required checks enforced by branch protection rules

Repository Structure (relevant parts)


.github/
workflows/
ci.yml
deploy-canary.yml
apps/
web/                  # Next.js 14 app
packages/
ui/                   # shared components
config/               # ESLint, TS config
tests/
e2e/                  # Playwright specs
seeds/                # Firebase test data

Workflow 1: CI (PR and main)

./github/workflows/ci.yml

name: CI

on:
  pull_request:
    branches: [ main ]
  push:
    branches: [ main ]

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

jobs:
  setup:
    name: Setup
    runs-on: ubuntu-latest
    outputs:
      node: ${{ steps.matrix.outputs.node }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
      - uses: pnpm/action-setup@v4
        with:
          version: 9
      - name: Install
        run: pnpm install --frozen-lockfile

  lint_typecheck:
    name: Lint and TypeCheck
    needs: setup
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
      - uses: pnpm/action-setup@v4
        with:
          version: 9
      - run: pnpm install --frozen-lockfile
      - run: pnpm eslint .
      - run: pnpm tsc -p tsconfig.json --noEmit

  build:
    name: Build
    needs: [setup, lint_typecheck]
    runs-on: ubuntu-latest
    env:
      NEXT_TELEMETRY_DISABLED: 1
      NODE_ENV: production
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
      - uses: pnpm/action-setup@v4
        with:
          version: 9
      - run: pnpm install --frozen-lockfile
      - name: Build web
        run: pnpm --filter ./apps/web build
      - name: Upload build artifact
        uses: actions/upload-artifact@v4
        with:
          name: web-build
          path: apps/web/.next

  test_emulators:
    name: Firebase Emulator Tests
    needs: build
    runs-on: ubuntu-latest
    services:
      firestore:
        image: docker.io/bitnami/firebase-emulator:latest
        ports:
          - 4000:4000
          - 8080:8080
          - 9099:9099
          - 9199:9199
    env:
      FIREBASE_AUTH_EMULATOR_HOST: localhost:9099
      FIRESTORE_EMULATOR_HOST: localhost:8080
      GCLOUD_PROJECT: test-project
      NODE_ENV: test
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
      - uses: pnpm/action-setup@v4
        with:
          version: 9
      - run: pnpm install --frozen-lockfile
      - name: Seed test data
        run: pnpm tsx tests/seeds/seed.ts
      - name: Unit and integration tests
        run: pnpm test -- --reporter=junit --coverage
      - name: Upload coverage
        uses: actions/upload-artifact@v4
        with:
          name: coverage
          path: coverage

  e2e_smoke:
    name: Playwright Smoke (headless)
    needs: test_emulators
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
      - uses: pnpm/action-setup@v4
        with:
          version: 9
      - run: pnpm install --frozen-lockfile
      - name: Install browsers
        run: pnpm exec playwright install --with-deps
      - name: Run smoke tests
        env:
          BASE_URL: http://localhost:3000
        run: |
          pnpm --filter ./apps/web dev & sleep 8
          pnpm exec playwright test tests/e2e/smoke.spec.ts --reporter=line
      - name: Upload Playwright artifacts
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: playwright-artifacts
          path: |
            playwright-report
            test-results

What this does:

Cancels superseded runs automatically
Builds once and reuses artifacts
Spins Firebase emulators for realistic tests
Runs Playwright in headless mode against a local dev server

Workflow 2: Canary Deploy to Edge

./github/workflows/deploy-canary.yml

name: Deploy Canary

on:
  workflow_run:
    workflows: ["CI"]
    types: [completed]
    branches: [ main ]

permissions:
  contents: read
  deployments: write
  id-token: write

concurrency:
  group: deploy-canary
  cancel-in-progress: false

jobs:
  gate:
    name: Require green CI
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      - run: echo "CI passed, proceeding to deploy."

  deploy:
    name: Deploy to next.pocketportfolio.app
    needs: gate
    runs-on: ubuntu-latest
    environment:
      name: canary
      url: https://next.pocketportfolio.app
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
      - uses: pnpm/action-setup@v4
        with:
          version: 9
      - run: pnpm install --frozen-lockfile
      - name: Build
        run: pnpm --filter ./apps/web build
      - name: Vercel Deploy (Edge)
        uses: amondnet/vercel-action@v25
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
          vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
          working-directory: ./apps/web
          scope: ${{ secrets.VERCEL_ORG_ID }}
          prod: false
      - name: Health check
        run: |
          curl -fsSL https://next.pocketportfolio.app/api/health || exit 1
          curl -fsSL https://next.pocketportfolio.app/api/health-price || exit 1

Notes:

workflow_run ensures deploy runs only after CI succeeds on main.
Environment protection rules can require manual approval inside GitHub before the deploy job starts.
We target Edge by configuring Vercel project functions to run on the Edge runtime.

Health Checks and Auto-Rollback

We keep deploys safe with a simple pattern:

After deployment, curl health and quote endpoints
If any return non-2xx, mark the job failed
A failing canary keeps production untouched

Optional rollback step (if you use Vercel Protected Branches):

      - name: Roll back canary to previous deployment
        if: failure()
        run: |
          echo "Rolling back..."
          # Example: pin to previous successful alias or commit sha via Vercel CLI

Speed and Stability Techniques

Caching: actions/setup-node with cache: pnpm cuts install time.
Concurrency: single deploy job at a time prevents environment drift.
Artifacts: store build output and Playwright results for debugging.
Separate concerns: CI proves code is safe; deploy workflow just ships.
Emulators: Firebase emulator suite catches integration issues locally and in CI.

Failure Modes We Handle

Stuck third-party provider: Playwright tests stub provider responses for critical flows.
Flaky UI timing: Playwright uses test id selectors and realistic waits.
Race conditions: matrix and concurrency settings keep builds deterministic.

Minimal Smoke Spec Example

tests/e2e/smoke.spec.ts

import { test, expect } from '@playwright/test';

test('dashboard loads and shows health badge', async ({ page }) => {
  await page.goto('/');
  await expect(page.getByTestId('health-badge')).toHaveText(/healthy|degraded/);
});

test('price endpoint responds', async ({ request }) => {
  const res = await request.get('/api/health-price');
  expect(res.ok()).toBeTruthy();
});

What To Measure

CI total duration (target: under 8 minutes for PRs)
Flake rate (target: below 1 percent over 30 days)
Canary failure rate and mean time to recovery
Playwright runtime and retries per suite

Assets

Workflow diagram (Setup -> Lint -> Build -> Emulators -> Playwright -> Canary Deploy)
Screenshots of GitHub Checks and Environment approvals
Example Playwright report

TL;DR

Every commit runs the same path production will run: build, test, verify, deploy, and prove it is healthy.
If any step fails, the release stops itself. That is CI/CD that ships itself.

From Code Push to Docker Hub: CI/CD with GitHub Actions

Tue, 14 Oct 2025 05:04:53 +0000

Imagine you’re running a bakery. Every morning, you bring fresh ingredients (your new code). But instead of kneading, baking, packaging, and delivering each loaf by hand, you want a conveyor belt that handles everything the moment the ingredients arrive.

That conveyor belt is your CI/CD pipeline.
Each time you git push, it builds, tests, packages, and ships your product automatically.

In this article, we’ll create that conveyor belt for your Node.js app using GitHub Actions and Docker.

Why Automate Docker Builds?

Why It Matters
Manual builds are slow, repetitive, and error-prone. Automation brings consistency and peace of mind.

Explain Like a Friend
Think of manually assembling furniture for every order — you’ll eventually forget screws or swap panels. A factory line ensures the same result every single time. CI/CD is that factory line for software.

Real-World Example
A small dev team pushes hotfixes daily. Without automation, they rebuild locally, tag manually, and sometimes push to the wrong repo. With GitHub Actions, every push triggers a clean, predictable build → tag → push pipeline.

Action Step
Write down every manual command you currently run to deploy your Docker image. That’s your “to-automate” checklist.

Prerequisites: Accounts, Secrets & Permissions

Why It Matters
Your automation can’t log in or deploy if it doesn’t have the right keys.

Explanation
Think of GitHub and Docker Hub as two warehouses. Your CI/CD robot needs secure keys to both: one to collect the code, the other to store the built product (your image).

Real-World Example
In the demo, the author logs into Docker Hub using encrypted secrets:

DOCKER_HUB_USERNAME
DOCKER_HUB_TOKEN

These secrets are stored safely in GitHub → Settings → Secrets → Actions never in your source code.

Action Steps

Create or log into your Docker Hub account.
Generate a personal access token (instead of using your password).
In GitHub, go to Settings → Secrets → Actions, and add:

DOCKER_HUB_USERNAME

DOCKER_HUB_TOKEN

Writing the Workflow (main.yaml) — Step by Step

Why It Matters
The workflow file is your recipe — the step-by-step plan your robot will follow.

Explanation
In .github/workflows/main.yaml, you define:

When to run: (trigger event, like push)
What to run: (the jobs and steps)
How to run: (what tools or actions to use)

Key Parts

on: push: “Start the oven when new ingredients arrive.”
jobs: “Each job is a workstation — baking, packaging, shipping.”
actions/checkout@v3: “Fetch ingredients from the storage (repo).”
docker/login-action@v2: “Unlock the warehouse with your keycard (secret).”
docker/build-push-action@v3: “Bake and ship the final product.”

Example Workflow

name: Build and Push Docker Image

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_HUB_USERNAME }}
          password: ${{ secrets.DOCKER_HUB_TOKEN }}

      - uses: docker/build-push-action@v3
        with:
          context: .
          push: true
          tags: yourname/app:latest

⚠️ Common Pitfalls

Wrong Dockerfile path → build fails.
Missing or misnamed secrets → login fails silently.
Forgot push: true → image never uploads.

✅ Action Step
Commit your file to .github/workflows/main.yaml and push it. Your pipeline is ready.

Build & Push: Watching It Run

Why It Matters
Seeing it work builds confidence that your automation truly works.

Explanation
Push your code, and watch:

GitHub detects the push.
Actions triggers the job.
The workflow checks out code, logs in to Docker Hub, builds, and pushes the image.

Real-World Example
In the demo, after pushing a small code change, the author refreshed Docker Hub and saw the new image tagged latest. No manual typing, no Docker commands.

Action Steps

Edit a small file (e.g., README).
Run git push.
Open GitHub → Actions tab → watch logs.
Open Docker Hub → confirm the new tag.

Counterpoints & Limitations

Private repos or registries: Require additional permissions or tokens.
Multi-service setups: Need multiple jobs or build matrix strategies.
Large images: Consider caching layers for faster builds.
Security: Always scan base images and protect secrets carefully.

Mini Case Study: “Solo Developer to One-Click Deployment”

Before:
X, a solo Node.js developer, manually built and pushed Docker images every update — often forgetting tags or pushing the wrong version.

After GitHub Actions:

Added main.yaml
Configured Docker Hub secrets
Now, every git push builds + pushes automatically

He cut his deployment time from 10 minutes to under 1, and never mistakes again.

Conclusion — From Kitchen Chaos to Conveyor Belt

We began with a bakery. You don’t want to bake, pack, and ship every loaf by hand. You want a conveyor belt that works reliably.

GitHub Actions and Docker give you that belt. As soon as you push code, your automation handles the rest — repeatable, consistent, hands-off.

Take this workflow file, plug in your secrets, push a change, and watch your pipeline come alive.

Automate your open-source project's builds & deployments with CI/CD using GitHub Actions!

Thu, 02 Oct 2025 07:00:54 +0000

Building CI/CD Pipelines (Without Losing Your Mind)

Beginner Level

Hey everyone! As members of the open-source community, we're all passionate about building awesome things – from libraries that power the internet to tools that make developers’ lives easier. But sometimes, getting those amazing contributions into production can feel… well, a bit like herding cats. That's where CI/CD pipelines come in!

What is a CI/CD Pipeline, Anyway? (Don't worry, it's not as scary as it sounds)

CI/CD stands for Continuous Integration and Continuous Delivery/Deployment. Think of it as an automated assembly line for your code.

Continuous Integration (CI): Whenever someone commits code to your repository, the CI system automatically pulls that code, builds it, runs tests, and checks for integration issues. It's like constantly merging small updates instead of waiting for a massive, potentially disastrous, merge at the end. This helps catch bugs early and keeps your codebase healthy.
Continuous Delivery (CD): Takes the CI step a little further by automating the process of releasing your code to a staging or testing environment. It ensures that your software is always in a deployable state.
Continuous Deployment (also CD): The ultimate goal! Automates the entire release process, including deploying code directly to production after passing all tests. This allows for faster feedback loops and quicker delivery of value to users.

Why Should We Care? (Besides Saving Our Sanity)

For open-source projects, a solid CI/CD pipeline offers huge benefits:

Faster Feedback: Developers get instant notifications when their code breaks something.
Reduced Risk: Automated tests catch bugs before they reach users. (Nobody likes a surprise bug!)
Increased Confidence: Knowing your code is consistently tested and deployed gives you peace of mind.
Easier Collaboration: Everyone benefits from clear, automated workflows.
More Time for Innovation: Less time spent on manual deployment means more time coding!

Building Your Own Pipeline

Okay, enough theory. Let's dive into how to build a CI/CD pipeline. There are tons of tools out there – Jenkins, GitLab CI, GitHub Actions, CircleCI, Azure DevOps… the list goes on! Don’t feel overwhelmed; you don't need to master everything at once.

I'll focus on GitHub Actions here, as it's widely used and integrates seamlessly with GitHub repositories (which is probably where your awesome open-source projects live). It also has a generous free tier – perfect for getting started!

Here’s a basic workflow example:

Create a .github/workflows directory in your repository. This is where you'll store your workflow files.
Create a YAML file (e.g., main.yml) inside the directory. This file defines the steps of your pipeline. Here’s an example:

name: CI/CD Pipeline

on:
  push:
    branches:
      - main  # Trigger the workflow on pushes to the 'main' branch

jobs:
  build:
    runs-on: ubuntu-latest  # Use a Linux runner

    steps:
      - uses: actions/checkout@v3 # Checkout the code from the repository

      - name: Set up Node.js 16
        uses: actions/setup-node@v3
        with:
          node-version: 16

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test  # Replace with your testing command (e.g., pytest, rspec)

      - name: Build the project
        run: npm run build # Replace with your build command

      - name: Deploy to staging (optional)
        if: github.ref == 'refs/heads/main'
        run: |
          # Add your deployment commands here - e.g., using SSH, cloud provider CLI tools etc.
          echo "Deploying to staging..."

Let’s break down that YAML:

name: A descriptive name for your workflow.
on: Specifies when the workflow should run (in this case, on pushes to the main branch).
jobs: Defines a set of tasks to be executed in parallel or sequentially. Here we have one job called build.
runs-on: Specifies the virtual environment where your job will run. ubuntu-latest is a common choice.
steps: A list of individual tasks to perform within the job. Each step uses pre-built actions from the GitHub Actions marketplace (like actions/checkout@v3).

Important Notes and Tips:

Actions Marketplace: The GitHub Actions marketplace has tons of community-created actions for everything from linting your code to sending Slack notifications on build failures. Explore it!
Secrets Management: Don't hardcode API keys or passwords in your workflow files! Use GitHub Secrets (Settings -> Secrets -> Actions) instead. It's much safer.
Testing is Key: Write good tests! They are the foundation of a robust CI/CD pipeline. Aim for high test coverage.
Branching Strategy: Consider adopting a branching strategy like Gitflow to streamline your development process.
Notifications: Configure notifications (e.g., Slack, email) to be alerted about build failures and deployments.

Troubleshooting: Because Things Always Go Wrong

Expect things to break! Your first pipeline won’t be perfect. Here are a few common troubleshooting tips:

Check the logs: The GitHub Actions UI provides detailed logs for each step of your workflow. Read them carefully!
Permissions: Make sure your workflow has the necessary permissions to access your repository and deploy to your target environment.
Dependencies: Double-check that all dependencies are installed correctly.
Don't Panic: Seriously, it happens to everyone. Debugging is part of the process!

Resources to Explore

GitHub Actions Documentation: https://docs.github.com/en/actions
GitLab CI Documentation: https://docs.gitlab.com/ee/ci/
CircleCI Documentation: https://circleci.com/docs/

The Takeaway

Building a CI/CD pipeline is an investment in the future of your open-source project. It might seem daunting at first, but it’s worth the effort. By automating your build, test, and deployment processes, you can free up time to focus on what truly matters – writing awesome code!

Now go forth and automate! And if you have any questions or tips of your own, share them in the comments below!

(P.S. If you accidentally deploy a broken version of your project to production, just blame the bot. It's always a good strategy.)

Enhancing Git Security and Workflow: A Comprehensive Guide to Signed Commits and a Linear History

Mon, 01 Sep 2025 12:00:38 +0000

In the world of version control, maintaining a secure and clean project history is crucial, especially for collaborative and open-source projects. This guide breaks down two essential best practices—signed commits and a linear history—and provides detailed steps on how to implement them.

1. The Power of Signed Commits

A signed commit is cryptographically verified to have been made by the person to whom it is attributed. This is a critical security measure in modern software development. It prevents malicious actors from impersonating trusted contributors and provides an undeniable audit trail.

How It Works

Signed commits rely on asymmetric cryptography using a public/private key pair. You use your private key to digitally sign your commits, and others can use your publicly available key to verify the signature.

Private Key: A secret key stored securely on your local machine, often protected by a strong passphrase. You use this to create a digital signature for each commit.
Public Key: This key is derived from your private key and can be shared freely. You upload it to your GitHub account.

When you push a signed commit, GitHub uses your public key to verify that the signature on the commit was created by your private key. If the signatures match, the commit gets a green "Verified" badge, guaranteeing non-repudiation.

How to Implement Signed Commits

Follow these steps to generate a GPG key, add it to GitHub, and configure Git to automatically sign your commits.

Install GPG:
Ensure you have GPG (GNU Privacy Guard) installed on your machine.
- macOS: brew install gpg
- Windows: Download from the GnuPG website.
- Linux (Debian/Ubuntu): sudo apt-get install gpg
Generate a GPG Key:
Use this command to generate a new key. Follow the prompts to select the key type, size, and set a strong passphrase.
```
gpg --full-generate-key
```
Export Your Public Key:
First, list your secret keys to get your key ID.
```
gpg --list-secret-keys --keyid-format=long
```
Your key ID will be a 16-character string in the output (e.g., 3AA5C34371567BD2). Then, export the public key.
```
gpg --armor --export [your-key-ID]
```
Copy the full output, including the -----BEGIN PGP PUBLIC KEY BLOCK----- and -----END PGP PUBLIC KEY BLOCK----- lines.
Add the Key to GitHub:
Go to your GitHub Settings > SSH and GPG keys and click "New GPG key." Paste the public key you just copied and save. Your account is now ready to verify signed commits.

Configure Git:
Tell Git which key to use for signing and enable automatic commit signing globally.

# Tell Git about your signing key
git config --global user.signingkey [your-key-ID]

# Automatically sign all commits
git config --global commit.gpgsign true

From now on, every commit you make will be automatically signed. If you prefer to sign commits on a per-commit basis, you can use the -S flag: git commit -S -m "Your commit message".

Note: For GitHub Actions, you cannot use a local GPG key, as the runner is a temporary virtual machine. Instead, GitHub automatically signs commits made by the github-actions[bot] user via the GitHub API, providing a verified commit for your automated workflows.

2. The Discipline of a Linear History

In addition to securing individual commits, maintaining a clean project history is vital for team collaboration. A linear history ensures your Git commits follow a single, straight line without the usual branching and merging. It makes a project’s history incredibly easy to read and manage.

How It's Achieved: The Rebase Workflow

A linear history is primarily achieved by using git rebase instead of git merge. This rewrites your branch's history to place your commits on top of the latest version of the main branch.

Here is a typical rebase workflow for a feature branch:

Update your local main branch:
```
git checkout main
git pull
```
Move your feature branch's commits on top of main:
```
git checkout my-feature-branch
git rebase main
```

If you encounter conflicts during the rebase, resolve them, add the changes (git add .), and then run git rebase --continue. Once the rebase is complete, your feature branch will have a clean, linear history, and you can push your changes.

Interactive Rebase for Cleaning Up Commits

Use git rebase -i to clean up your commit history before pushing. This is perfect for condensing multiple work-in-progress commits into a single, meaningful commit.

# Rebase the last 5 commits on your current branch
git rebase -i HEAD~5

Pushing Rebased Commits

Because git rebase rewrites history, a standard git push will fail. You must use a force push, but the safest way is with the --force-with-lease flag. This prevents you from accidentally overwriting someone else's work.

git push --force-with-lease

Merging in a Linear Workflow

In a linear workflow, you still use a "merge" action, but you do it via pull requests on platforms like GitHub, which offer specific types that avoid creating a merge commit:

Fast-Forward Merge: If your feature branch is a direct extension of the main branch, Git simply moves the main pointer forward.
Squash and Merge: This combines all your commits into a single, new commit on the main branch, which is great for keeping the main branch history clean.
Rebase and Merge: This performs a rebase and then a fast-forward merge, preserving all of your individual commits in a clean, linear order.

3. Enforcing Best Practices with Branch Protection Rules

Once you understand these concepts, you can enforce them using GitHub's branch protection rules. These rules are a powerful administrative tool for ensuring the integrity of your key branches (like main or develop).

To configure them, navigate to Settings > Branches in your GitHub repository and click "Add rule."

The Most Useful Rules

Require signed commits: This prevents anyone from merging a pull request that contains an unsigned commit. It's a non-negotiable step for maintaining a secure project.
Require linear history: This prevents the use of standard merge commits, forcing all merges to be a rebase or squash. It's an essential setting for maintaining a clean history.
Restrict push access: This allows you to specify that only certain users or teams (like administrators) can push directly to a protected branch, forcing all other changes to go through a pull request.
Restrict who can create and delete branches: This provides a safety net against accidental or malicious deletions by preventing unauthorized users from creating branches that match a protection rule or from deleting a critical branch.

GitHub workflows tips and tricks

Thu, 28 Aug 2025 06:54:30 +0000

I've quite a lengthy experience with GitHub workflows, but not up to the point where I can claim I'm an expert. However, I recently developed a new workflow, and it prompted me to write this post. Feel free to add your own.

What are GitHub workflows?

>A workflow is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked in to your repository and will run when triggered by an event in your repository, or they can be triggered manually or at a defined schedule.

>Workflows are defined in the .github/workflows directory in a repository. A repository can have multiple workflows, each of which can perform a different set of tasks, such as:

> Building and testing pull requests
> Deploying your application every time a release is created
>* Adding a label whenever a new issue is opened

>-- About workflows

As such, a workflow is comparable to a Jenkins job, implemented in YAML instead of XML. Yet, the main difference is that the workflow configuration is stored inside the code repository, contrary to a legacy Jenkins job configuration. It doesn't look like much, but it allows using source code management approaches, including versioning and rolling back. Years ago, I worked for a customer whose DevOps team implemented a Puppet-based approach to reconstruct Jenkins jobs so the Puppet config could be stored in Git. It was a huge effort!

Note that GitHub was quite late to the party. Before it implemented workflows, I used a third-party service called Travis CI that worked the same way. I switched mainly because Travis became paid and secondarily because workflows are natively part of GitHub.

Tip: Use the correct semantics: they are called GitHub workflows. GitHub Actions are entirely different.

GitHub Actions

GitHub workflows are composed of jobs, which themselves are composed of steps. Steps reference run commands, and a couple of optional parameters, including a name.

jobs:
  metrics:
    runs-on: my-image                              #1
    steps:
      - name: Install dependencies via Poetry      #2
        run: poetry install                        #3

OCI image on which the workflow runs
Step name
Step command

GitHub Actions are reusable components that offer alternatives to repeating the same command over and over.

>An action is a pre-defined, reusable set of jobs or code that performs specific tasks within a workflow, reducing the amount of repetitive code you write in your workflow files. Actions can perform tasks such as:

> Pulling your Git repository from GitHub
> Setting up the correct toolchain for your build environment
>* Setting up authentication for your cloud provider

>You can write your own actions, or you can find actions to use in your workflows in the GitHub Marketplace.
>For example, instead of executing git checkout, you can use the checkout action.

>-- GitHub Action

jobs:
  metrics:
    runs-on: my-image
    steps:
      - uses: actions/checkout@v5                  #1
        with:                                      #2
          fetch-depth: 0
          submodules: recursive

Reference a GitHub Action
Action parameters

I'm a big fan of not reinventing the wheel. GitHub Actions play a big role in that.

Tip: Prefer GitHub Actions over ad-hoc commands when possible.

Choosing the right Action

The GitHub Marketplace hosts plenty of actions. Actions are listed by categories. You can filter by creator type and sort by popularity.

When choosing an action, you should exert the same care as when bringing in any other dependency. Here are a couple of criteria to help you:

Vendor: prefer verified creators
License type: Open Source vs. closed source. With the former, check the exact terms; the Apache v2 license is very different from the GPL one.
Pricing for commercial actions
Check the source code repository of actions that display it and check the following information:
Inception date
Activity, including the repartition of commits per committer, the number of open issues, the mean time for fixing issues, etc.
** Documentation (reference material, tutorials, how-to guides, and explanations)
Community, if any
Support

Tip: Be as careful in choosing a GitHub Action as in choosing any other dependency.

Know your Actions

As the previous tip, this one stems from a more generic one—I speak from experience. I was developing a workflow to package a Java application. I was heavily using the workflow, and the job had to download the dependencies at every run.

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-java@v4                #1
        with:
          distribution: temurin
          java-version: 21
      - uses: actions/cache@v4                     #2
        with:
          path: ~/.m2/repository                   #3
          key: ${{ platform }}-maven--${{ hashFiles('**/pom.xml') }} #4
          restore-keys: |
            ${{ runner.os }}-maven-                #4

Install a JDK
Set up a cache. The cache is generic and can cache files across runs.
Cache the local Maven repository
Cache dependencies. The key uses the runner OS, which doesn't change, and the POM's hash. Hence, the step creates a new cache each time the POM changes.

Yet, reading the documentation, I realized I could achieve the same in a much more straightforward way:

>The action has a built-in functionality for caching and restoring dependencies. It uses toolkit/cache under hood for caching dependencies but requires less configuration settings. Supported package managers are gradle, maven and sbt. The format of the used cache key is setup-java-${{ platform }}-${{ packageManager }}-${{ fileHash }}, where the hash is based on the following files:

>* maven: **/pom.xml

>-- Caching packages dependencies

Thus, I replaced the above snippet with the following:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 21
          cache: maven                             #1

This is it

Tip: Thoroughly read the documentation of actions. Spending one hour on the documentation can help you save man-days of effort.

Pin your dependency version

This section also takes generic advice and applies it to GitHub workflows' version. You find versions in at least two places: the OCI image and GitHub Actions' version.

You may have noticed the runs-on: ubuntu-latest in the previous snippets. At the moment of this writing, it points to ubuntu-24.04. As time passes, it will point to the latest version, with different libraries' versions. It could cause a failure during the workflow execution, or worse, change the output in ways you wouldn't notice until it's too late. You'd better set a specific version. Check https://github.com/actions/runner-images[all available images].

Actions' versioning works differently, as they point to a GitHub repo's reference: either a tag or a commit SHA. While the OCI image is in GitHub's hands, the action is the responsibility of its provider. It means anybody with commit rights could change the content of an underlying tag. If you take security seriously, you must pin to a commit.

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@08c6903             #1

Pin to a specific commit

Tip: Take security seriously and pin actions to a specific commit.

Use the job summary

Each of your workflow steps probably outputs lots of logs. In a regular workflow, the overall amount of log lines can be quite huge. Some of them might be useful, some of them might not be, but because there's only a standard output and standard error, everything ends up in the same place. Yet, you may want to focus on specific information, e.g., the number of tests run or the percentage of code coverage, in case you don't send these data somewhere else. GitHub makes it straightforward to add the data you want in the job summary.

>You can set some custom Markdown for each job so that it will be displayed on the summary page of a workflow run. You can use job summaries to display and group unique content, such as test result summaries, so that someone viewing the result of a workflow run doesn't need to go into the logs to see important information related to the run, such as failures.

>Job summaries support GitHub flavored Markdown, and you can add your Markdown content for a step to the GITHUB_STEP_SUMMARY environment file. GITHUB_STEP_SUMMARY is unique for each step in a job.

>-- Adding a job summary

Here's a sample from Apache Arrow:

- name: Show inputs
  run: |
    echo "upload_artifacts: ${{ inputs.upload_artifacts }}" >> $GITHUB_STEP_SUMMARY
    echo "schedule: ${{ github.event.schedule }}" >> $GITHUB_STEP_SUMMARY
    echo "ref: ${{ github.ref }}" >> $GITHUB_STEP_SUMMARY

The result is:

Tip: Use GitHub job summary to enhance developer experience.

Understand workflows' lifecycle

Workflows run steps sequentially. A failing step cancels all remaining steps, and the workflow ends up in a Failure state. In the example above, it means we won't get any testing summary at all if any of the subsequent step fails. It's possible to bypass this default behavior by using the counterintuitive if condition.

>You can use the following status check functions as expressions in if conditionals. A default status check of success() is applied unless you include one of these functions.

>-- Status check functions

GitHub uses success() by default, but options include always(), cancelled(), and failure().

- name: Show inputs
  if: ${{ always() }}                              #1
  run: |
    echo "upload_artifacts: ${{ inputs.upload_artifacts }}" >> $GITHUB_STEP_SUMMARY
    echo "schedule: ${{ github.event.schedule }}" >> $GITHUB_STEP_SUMMARY
    echo "ref: ${{ github.ref }}" >> $GITHUB_STEP_SUMMARY

Always run the step, regardless of whether the previous steps were successful or not

Now imagine the following sequence:

- name: Step that may fail
  run: whatever
- name: Execute unit tests
  run: ./mvnw -B test                              #1
- name: Test Summary
  if: ${{ always() }}
  uses: test-summary/action@31493c7                #2

Running unit tests also generates JUnit reports
Use the generated JUnit reports to write a step summary

If the first step fails, the summary executes regardless of whether tests were run. If they didn't, it would fail. To avoid this, we must refine the condition further so that the summary step only runs if the unit test step did.

- name: Step that may fail
  run: whatever
- name: Execute unit tests
  id: test                                         #1
  run: ./mvnw -B test
- name: Test Summary
  if: ${{ always() && steps.test.conclusion == 'success'}} #2
  uses: test-summary/action@31493c7

Set the step's id
Run only if the test step runs successfully

It's only a simple example, but it offers interesting options.

Tip: Know workflows' lifecycle and use it to your advantage.

Test locally

Lots of organizations enforce strict GitHub rules. The most widespread one is that you can't push to master: every commit must go through a pull request. While it makes sense for established projects, it prevents starting projects from iterating fast while retaining the commit history. In the context of developing GitHub workflows, it's definitely crippling.

Comes the act project:

>"Think globally, act locally"

>Run your GitHub Actions locally! Why would you want to do this? Two reasons:

> Fast Feedback - Rather than having to commit/push every time you want to test out the changes you are making to your .github/workflows/ files (or for any changes to embedded GitHub actions), you can use act to run the actions locally. The environment variables and filesystem are all configured to match what GitHub provides.
> Local Task Runner - I love make. However, I also hate repeating myself. With act, you can use the GitHub Actions defined in your .github/workflows/ to replace your Makefile!

>-- Introduction to act

act has a GitHub CLI integration that triggers the workflow according to the correct event. Let's emulate a push:

gh act push

Here's the output excerpt when images and actions have already been downloaded:

INFO[0000] Using docker host 'unix:///var/run/docker.sock', and daemon socket 'unix:///var/run/docker.sock'
[workflow.yml/test] ⭐ Run Set up job
[workflow.yml/test]   Start image=catthehacker/ubuntu:act-22.04
[workflow.yml/test]     docker pull image=catthehacker/ubuntu:act-22.04 platform= username= forcePull=true
[workflow.yml/test]     docker create image=catthehacker/ubuntu:act-22.04 platform= entrypoint=["tail" "-f" "/dev/null"] cmd=[] network="host"
[workflow.yml/test]     docker run image=catthehacker/ubuntu:act-22.04 platform= entrypoint=["tail" "-f" "/dev/null"] cmd=[] network="host"
[workflow.yml/test]     docker exec cmd=[node --no-warnings -e console.log(process.execPath)] user= workdir=
[workflow.yml/test]   ✅  Success - Set up job
[workflow.yml/test]   ☁  git clone 'https://github.com/actions/setup-java' # ref=v4
[workflow.yml/test] ⭐ Run Main actions/checkout@v4
[workflow.yml/test]     docker cp src=/Users/nico/projects/act-sample/. dst=/Users/nico/projects/act-sample
[workflow.yml/test]   ✅  Success - Main actions/checkout@v4 [9.211777902s]
[workflow.yml/test] ⭐ Run Main Setup JDK
[workflow.yml/test]     docker cp src=/home/nico/.cache/act/actions-setup-java@v4/ dst=/var/run/act/actions/actions-setup-java@v4/
[workflow.yml/test]     docker exec cmd=[/opt/acttoolcache/node/18.20.8/x64/bin/node /var/run/act/actions/actions-setup-java@v4/dist/setup/index.js] user= workdir=
[workflow.yml/test]   ❓  ::group::Installed distributions
| Resolved Java 21.0.8+9.0.LTS from tool-cache
| Setting Java 21.0.8+9.0.LTS as the default
| Creating toolchains.xml for JDK version 21 from temurin
| Writing to /root/.m2/toolchains.xml
|
| Java configuration:
|   Distribution: temurin
|   Version: 21.0.8+9.0.LTS
|   Path: /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.8-9.0.LTS/x64
|
[workflow.yml/test]   ❓  ::endgroup::
[workflow.yml/test]   ❓ add-matcher /run/act/actions/actions-setup-java@v4/.github/java.json
| Creating settings.xml with server-id: github
| Writing to /root/.m2/settings.xml
[workflow.yml/test]   ⚙  ***
| Cache Size: ~50 MB (52710428 B)
| [command]/usr/bin/tar -xf /tmp/c8ef4803-85c1-4867-ac2d-442dbce79755/cache.tzst -P -C /Users/nico/projects/act-sample --use-compress-program unzstd
| Cache restored successfully
| Cache restored from key: setup-java-linux-x64-maven-ef0e54e9035c18b60db7ea0af5e2f0c4cc5445dd6a2a2a672b91e14f14e7e4c2
[workflow.yml/test]   ✅  Success - Main Setup JDK [2.514565962s]
[workflow.yml/test]   ⚙  ::set-env:: JAVA_HOME=/opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.8-9.0.LTS/x64
[workflow.yml/test]   ⚙  ::set-env:: JAVA_HOME_21_X64=/opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.8-9.0.LTS/x64
[workflow.yml/test]   ⚙  ::set-output:: distribution=Temurin-Hotspot
[workflow.yml/test]   ⚙  ::set-output:: path=/opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.8-9.0.LTS/x64
[workflow.yml/test]   ⚙  ::set-output:: version=21.0.8+9.0.LTS
[workflow.yml/test]   ⚙  ::set-output:: cache-hit=false
[workflow.yml/test]   ⚙  ::add-path:: /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/21.0.8-9.0.LTS/x64/bin
[workflow.yml/test] ⭐ Run Main Run "fast" tests
[workflow.yml/test]     docker exec cmd=[bash -e /var/run/act/workflow/2] user= workdir=
...
[workflow.yml/test]   ✅  Success - Main Run "fast" tests [20.920776212s]
[workflow.yml/test] ⭐ Run Post Setup JDK
[workflow.yml/test]     docker exec cmd=[/opt/acttoolcache/node/18.20.8/x64/bin/node /var/run/act/actions/actions-setup-java@v4/dist/cleanup/index.js] user= workdir=
| [command]/usr/bin/tar --posix -cf cache.tzst --exclude cache.tzst -P -C /Users/nico/projects/act-sample --files-from manifest.txt --use-compress-program zstdmt
| Cache Size: ~50 MB (52701753 B)
| Cache saved successfully
| Cache saved with the key: setup-java-Linux-x64-maven-ef0e54e9035c18b60db7ea0af5e2f0c4cc5445dd6a2a2a672b91e14f14e7e4c2
[workflow.yml/test]   ✅  Success - Post Setup JDK [1.01412383s]
[workflow.yml/test] ⭐ Run Complete job
[workflow.yml/test] Cleaning up container for job test
[workflow.yml/test]   ✅  Success - Complete job
[workflow.yml/test]   Job succeeded

I could write a couple of posts on act; I'll leave you to read the documentation.

Tip: Test your workflows locally to reduce your feedback cycle time.

Summary

Use the correct semantics, differentiate between workflows and actions.
Prefer GitHub Actions over ad-hoc commands.
Be as careful in choosing a GitHub Action as in choosing any other dependency.
Thoroughly read the documentation of each action you use.
Pin actions to a specific commit.
Use GitHub job summary to enhance developer experience.
Know workflows' lifecycle.
Test your workflows locally.

To go further:

Originally published at A Java Geek on August 24^th, 2025

Deploy your application on Vercel with GitHub Actions

Wed, 20 Aug 2025 17:26:29 +0000

A very common CI/CD pattern for frontend apps is: build in CI and deploy to production automatically when the code reaches main.
If you use Vercel, you can do this with a short and reliable GitHub Actions workflow that:

downloads your project's configuration and variables from Vercel,
builds the app in CI,
and deploys the already built artifacts to production.

In this article, we'll walk through it step by step and I'll give you some tips to help you understand what each line does.

Purpose of the workflow

Every time there is a push to main, the following should be executed:

Pull config from Vercel (includes production environment variables).
Reproducible build in CI.
Deploy that artifact (without rebuilding in Vercel).

This will give you predictable deployments that are easy to audit and debug.

General workflow structure

name: Vercel PRO deployment
on:
  push:
    branches:
      - main
jobs:
  deploy:
    name: deploy
    runs-on: ubuntu-latest
    steps:
      - id: checkout-step
        name: Checkout code
        uses: actions/checkout@v4
      - id: install-vercel-cli-step
        name: Install Vercel CLI
        run: npm install --global vercel@latest
      - id: pull-vercel-env-info-step
        name: Pull Vercel Environment Information
        run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN
          }}
      - id: build-vercel-artifacts-step
        name: Build Project Artifacts
        run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
      - id: deploy-vercel-artifacts-step
        name: Deploy Project Artifacts to Vercel
        run: vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}

Prerequisites
Create the secret VERCEL_TOKEN in your repository (Settings → Secrets and variables → Actions).
Either commit .vercel/project.json, or provide VERCEL_ORG_ID and VERCEL_PROJECT_ID as secrets when you do vercel pull.

Step by step

on: push (to main)
Each push to main triggers the production pipeline. If you prefer to only deploy when merging by PR, simply avoid pushing directly to main.

uses: actions/checkout@v4
Download your code to the runner so that the following tools (Vercel CLI) have it available.

npm install --global vercel@latest
Install the Vercel CLI.

Tip: to avoid surprises, you can set version: vercel@xx (or whatever you use on your team).

vercel pull --yes --environment=production
Bring the project configuration and production environment variables to .vercel/ on the runner.
In CI there are no interactive questions, so we use --yes.

You need:

.vercel/project.json in the repository or
VERCEL_ORG_ID and VERCEL_PROJECT_ID as variables/secrets.

vercel build --prod
Builds in CI using your framework (Next.js, SvelteKit, etc.) or what is defined in vercel.json.
The result is stored in .vercel/output and is exactly what you are going to deploy.

vercel deploy --prebuilt --prod
Uploads the already built artifact to production.
With --prebuilt, Vercel does not rebuild: what you tested in CI is what your user will see.

✅ Final result

With this workflow, each merge to main runs a clean build and deploys that same artifact to production in Vercel. You get:

reproducible builds,
faster deploys,
and clear CI logs for debugging.

Prefer to configure it visually?

Writing workflows by hand gives you total control, but sometimes you want speed with built-in validations.

With OctoLab, you can set up this same pipeline visually: choose actions, fill in fields, and the YAML is generated instantly, ready to commit.

Try it out: https://www.octolab.app/templates/vercel-pro-deployment

Conclusion

This workflow provides you with a clean CI → production flow on every push to main, using Vercel's recommended approach: pull → build → deploy. It's easy to adapt to previews, monorepos, or strict reproducibility (fixed Node and CLI).

Use it as a base and evolve it with caching, notifications, or environment gates as your team grows.

Unlocking AI-Native Development: Key Highlights from GitHub Galaxy 2025

Sun, 10 Aug 2025 19:31:41 +0000

Introduction
Recently, GitHub hosted Galaxy 2025, an all-virtual event spotlighting the future of AI-native software development. This gathering offered a firsthand look at how GitHub is redefining developer workflows — from enterprise-grade security to seamless AI-powered collaboration.

Highlights from Galaxy 2025

Keynote: Where AI Meets Enterprise Excellence
GitHub emphasized AI-native and agentic experiences, underscoring the importance of developer choice and robust security in modern software development ([GitHub Galaxy][2]).
Hands-On Secure Workflows
The event spotlighted secure DevOps workflows in action — showcasing tools that streamline collaboration while addressing vulnerabilities at scale.
Product Roadmap & GitHub Vision
Attendees gained insights into GitHub’s strategic vision and upcoming features designed to empower teams with AI-powered toolchains and automation.
Agentic AI & Developer Flow
Topics such as agentic AI, maintaining developer focus, and enhancing productivity at scale were central to discussions — critical as organizations strive to innovate faster than ever ([GitHub Universe][3], [X (formerly Twitter)][4]).

Why It Matters for Your Organization

GitHub Galaxy 2025 wasn’t just an event—it was a glimpse into the future of software development. Whether you're leading development teams or shaping digital strategies, the insights shared are a blueprint for staying competitive and secure in an AI-forward world.

Final Thoughts

The Galaxy logo itself—dynamic and charged with energy—reflects GitHub’s bold direction toward AI-native development. Let this be your inspiration to explore how AI-first workflows and enterprise-grade security can elevate your development lifecycle.

For more info, check out this link:
https://galaxy.github.com/

Let’s stay connected:

Instagram: https://www.instagram.com/angular_development/

Facebook: https://m.facebook.com/learnangular2plus/

Threads: https://www.threads.net/@angular_development

Medium: https://medium.com/@eraoftech

coderlegion: https://coderlegion.com/user/Sunny

Quora: https://neweraofcoding.quora.com/

YouTube: https://www.youtube.com/@neweraofcoding

LinkedIn: https://www.linkedin.com/company/infowebtech/

Hashnode: https://neweraofcoding.hashnode.dev/

GitHub: https://github.com/angulardevelopment/ | sunny7899

BlueSky: https://bsky.app/profile/neweraofcoding.bsky.social

Substack Newsletter: https://codeforweb.substack.com/

Pinterest: https://in.pinterest.com/tech_nerd_life/

dev.to: https://dev.to/sunny7899

Looking for web dev trainings: https://beginner-to-pro-training.vercel.app/

Software development services: https://infowebtechnologies.vercel.app/

Contribution to the web development community: https://code-for-next-generation.vercel.app/

Book a session: https://topmate.io/softwaredev

Telegram Channel: https://t.me/neweraofcoding

Slack Community: Invite

Discord Community: http://discord.gg/Nuc9YRngHz

Buy me a coffee on Ko-fi: https://ko-fi.com/softwaredev

Ebooks: https://apexsunshine.gumroad.com

Thank you for being a part of the community. Happy coding!

The Ultimate Guide to Mastering Git Commands: Everything You Need to Know

Fri, 21 Feb 2025 14:45:30 +0000

The Ultimate Guide to Mastering Git Commands: Everything You Need to Know

Git is the backbone of modern software development, enabling developers to track changes, collaborate seamlessly, and manage codebases with ease. Whether you're a beginner or an experienced developer, understanding Git commands is essential for efficient version control. In this comprehensive guide, we’ll dive deep into every Git command, explaining their purpose, usage, and best practices. By the end of this post, you'll be equipped with the knowledge to master Git like a pro!

1. Setting Up Git: The First Step in Your Journey

Before you start using Git, it's crucial to configure it properly. These initial steps ensure that your commits are correctly attributed and that Git behaves the way you want it to.

️ `git config`: Configuring Git Settings

This command allows you to set up user-specific configurations such as your name, email, and other preferences.

Usage:

git config --global user.name "Your Name"
git config --global user.email "*Emails are not allowed*"

Purpose:
These commands set your username and email globally across all repositories on your machine. This information will be attached to every commit you make.
Additional Tips:
- To check your current configuration, use:
```
git config --list
```
- You can also set repository-specific configurations by omitting the --global flag.

2. Creating and Initializing Repositories: Where It All Begins

`git init`: Initializing a New Repository

This command creates a new Git repository in your current directory. It sets up a .git folder where all the version control data will be stored.

Usage:
```
git init
```
Purpose:
Use this command when you’re starting a new project from scratch. It initializes a Git repository, allowing you to start tracking changes immediately.
Example:
If you have a project folder called my-project, navigate to it and run git init. Now, Git is ready to track changes in your project!

`git clone`: Cloning an Existing Repository

If you want to work on an existing project hosted on a remote server (like GitHub), you can use the git clone command.

Usage:

git clone https://github.com/username/repo.git

Purpose:
This command downloads the entire repository, including its history, to your local machine. It’s perfect for collaborating on open-source projects or working on team projects.
Example:
Suppose you want to contribute to a project on GitHub. You can clone the repository using the URL provided by the platform.

3. Checking the Status: Stay Updated with Your Work

`git status`: Understanding the State of Your Repository

This command provides a snapshot of your working directory and staging area. It tells you which files are modified, staged, or untracked.

Usage:
```
git status
```
Purpose:
Use this command to understand what’s happening in your repository. It helps you identify which files need to be committed or staged.
Example:
After making changes to your code, running git status will show you which files have been modified and whether they’re staged for commit.

4. Tracking and Staging Files: Preparing for Commit

`git add`: Adding Files to the Staging Area

Before committing changes, you need to stage them using the git add command. This moves files from the working directory to the staging area.

Usage:

git add <file-name>       # Add a specific file
git add .                 # Add all files in the current directory
git add -u                # Add only modified or deleted files (ignores new files)

Purpose:
This command prepares your changes for the next commit. It’s like telling Git, “Hey, I want these changes to be part of my next snapshot.”
Example:
If you’ve made changes to index.html and style.css, you can stage both files using git add index.html style.css.

✅ 5. Committing Changes: Saving Your Work

`git commit`: Finalizing Your Changes

Once your changes are staged, you can commit them to the repository. A commit is like a snapshot of your project at a specific point in time.

Usage:
```
git commit -m "Commit message"
```
Purpose:
This command saves your changes to the repository with a descriptive message. The commit message should explain what changes were made and why.
Example:
After staging your changes, you can commit them with a message like:
```
git commit -m "Added login functionality"
```
Pro Tip:
Use git commit -am "message" to stage and commit all tracked files in one step.

⏳ 6. Viewing the Commit History: Tracking Your Progress

️ `git log`: Exploring Your Commit History

This command displays the commit history of your repository, showing who made each commit, when it was made, and the associated message.

Usage:

git log
git log --oneline          # Display a concise summary
git log --author="name"    # Filter commits by author
git log --since="date"     # Show commits after a specific date

Purpose:
Use this command to review the history of your project. It’s especially useful for debugging or understanding how the project evolved over time.
Example:
Running git log --oneline will give you a quick overview of recent commits, showing only the commit hash and message.

7. Branching and Merging: Managing Parallel Workflows

`git branch`: Managing Branches

Branches allow you to work on different features or bug fixes simultaneously without affecting the main codebase.

Usage:

git branch                  # List all branches
git branch <branch-name>    # Create a new branch
git branch -d <branch-name> # Delete a branch

Purpose:
Branches are essential for collaboration. They let multiple developers work on different parts of a project without interfering with each other.
Example:
To create a new branch for a feature, use:
```
git branch feature-login
```

↔️ `git merge`: Combining Branches

Once you’ve completed work on a branch, you can merge it back into the main branch (usually main or master).

Usage:
```
git merge <branch-name>
```
Purpose:
This command integrates changes from one branch into another. It’s commonly used to merge feature branches into the main branch.
Example:
After finishing work on the feature-login branch, you can merge it into main using:
```
git checkout main
git merge feature-login
```

`git rebase`: Reapplying Commits

Rebasing allows you to move or combine a sequence of commits to a new base commit.

Usage:
```
git rebase <base>
```
Purpose:
Rebasing is useful for keeping a clean, linear commit history. It avoids unnecessary merge commits.
Example:
If you’re working on a feature branch and want to incorporate the latest changes from main, you can rebase your branch:
```
git checkout feature-login
git rebase main
```

8. Remote Repository Management: Collaborating with Others

`git remote`: Managing Remote Repositories

Remote repositories are hosted on platforms like GitHub, GitLab, or Bitbucket. They allow you to share your code with others.

Usage:

git remote -v               # List all remotes
git remote add <remote-name> <url>  # Add a new remote
git remote remove <remote-name>     # Remove a remote

Purpose:
This command helps you connect your local repository to a remote repository, enabling collaboration.

Example:
To add a remote repository called origin, use:

git remote add origin https://github.com/username/repo.git

`git fetch`: Fetching Changes from Remote

This command retrieves updates from a remote repository but doesn’t merge them into your local branch.

Usage:
```
git fetch <remote-name>
```
Purpose:
Use this command to see what changes have been made on the remote repository without affecting your local work.

`git pull`: Fetching and Merging Changes

This command fetches changes from the remote repository and merges them into your current branch.

Usage:
```
git pull <remote-name> <branch-name>
```
Purpose:
It’s a combination of git fetch and git merge. Use it to update your local branch with the latest changes from the remote.

`git push`: Pushing Changes to Remote

After committing changes locally, you can push them to the remote repository.

Usage:
```
git push <remote-name> <branch-name>
```
Purpose:
This command uploads your local commits to the remote repository, making them available to others.
Example:
To push your main branch to the origin remote, use:
```
git push origin main
```

️ 9. Tagging: Marking Important Milestones

️ `git tag`: Creating Tags

Tags are used to mark specific points in your repository’s history, usually for releases.

Usage:

git tag <tag-name>                     # Create a lightweight tag
git tag -a <tag-name> -m "Tag message" # Create an annotated tag

Purpose:
Tags are useful for marking versions of your project (e.g., v1.0, v2.0).
Example:
To create a tag for version 1.0, use:
```
git tag -a v1.0 -m "Version 1.0 release"
```

10. Resolving Conflicts: Handling Merge Issues

`git diff`: Identifying Differences

This command shows differences between commits, branches, or the working directory.

Usage:
```
git diff
git diff --staged
```
Purpose:
Use this command to identify conflicts or differences between files.

`git merge --abort`: Aborting a Merge

If a merge results in conflicts, you can abort the merge process.

Usage:
```
git merge --abort
```
Purpose:
This command cancels the merge and restores the branch to its previous state.

11. Undoing Changes: Fixing Mistakes

`git reset`: Resetting Changes

This command resets the current HEAD to a specified state.

Usage:

git reset --hard HEAD~1  # Discard the last commit
git reset --soft HEAD~1  # Keep changes in the working directory

Purpose:
Use this command to undo commits or reset your repository to a previous state.

`git revert`: Reverting Commits

This command creates a new commit that undoes changes introduced by a previous commit.

Usage:
```
git revert <commit-hash>
```
Purpose:
Use this command to safely undo changes without altering the commit history.

12. Cleaning Up: Removing Untracked Files

`git clean`: Removing Untracked Files

This command removes untracked files from your working directory.

Usage:
```
git clean -fd
```
Purpose:
Use this command to clean up your working directory by removing files that aren’t being tracked by Git.

13. Searching: Finding Specific Code

`git grep`: Searching for Strings

This command searches for specific strings within your repository.

Usage:
```
git grep "search-term"
```
Purpose:
Use this command to quickly find specific code snippets or text within your project.

14. Stashing Changes: Temporarily Saving Work

`git stash`: Stashing Changes

This command temporarily saves changes that aren’t ready to be committed.

Usage:

git stash
git stash list
git stash apply
git stash pop

Purpose:
Use this command to save your work in progress without committing it, allowing you to switch branches or fix urgent issues.

15. Ignoring Files: Keeping Your Repository Clean

`.gitignore`: Ignoring Files

Create a .gitignore file to specify files or directories that Git should ignore.

Purpose:
Use this file to prevent unnecessary files (like logs, temporary files, or dependencies) from being tracked by Git.

Conclusion: Mastering Git Commands

Git is a powerful tool that empowers developers to manage complex projects efficiently. By mastering these commands, you’ll be able to track changes, collaborate with others, and maintain a clean, organized codebase. Remember, practice makes perfect—experiment with these commands in your own projects to become a Git expert!

Happy Coding!

Ever wondered how to automate your development workflow effortlessly?

Tue, 18 Feb 2025 11:39:33 +0000

CI/CD refers to the combined practices of continuous integration (CI) and continuous delivery (CD), or deployment, which aims to streamline and accelerate the software development lifecycle.

It's a method that allows software development and IT teams to deliver code changes more frequently and reliably.

CI/CD is often referred to as a "CI/CD pipeline" and is supported by development and operations teams working together in an agile way.

Wondering how to bring CI/CD to your GitHub project?

GitHub Actions is the key to making it happen!

CI/CD can be made easier using GitHub Actions.

GitHub Actions is a CI/CD tool that automates software development workflows directly within your GitHub repository.

It allows you to automate tasks across pull requests and issues.

GitHub Actions is designed to simplify workflows with flexible automation and easy-to-use CI/CD capabilities.

It brings continuous integration (CI) and continuous delivery (CD) directly to the GitHub flow.

You’ll have to know a few core concepts before working with GitHub Actions:

Workflows: Automated processes comprised of jobs triggered by events; defined in YAML files within the .github/workflows directory.
Events: Triggers that start a workflow, such as creating a branch or opening a pull request.
Jobs: Tasks executed in a workflow, which can run in parallel.
Actions: Reusable code packages that perform complex tasks within workflows, like sending notifications. They can be custom or from the GitHub Marketplace.
Runners: The servers that execute your workflows.

You can tailor and build GitHub Actions to automate any tasks you need.

You’ll have to know some basic YAML to start your GitHub Actions journey.

However, you don’t have to know it by heart.

You can refer to the documentation and do it on your own.

The only thing you’ll have to remember is how it works.

If you ask me, "Have you worked with GitHub Actions?"—my answer is a definite "Yes!"

GitHub Actions will make your life easier when you are maintaining any open-source projects.

It will reduce your workload 10x when you have automated the CI/CD through GitHub Actions.

I have used GitHub Actions for my open-source project CampX. It made my maintenance job easier.

You can use GitHub Actions for any job that you have to carry out in your open-source project; it can be a simple or complex job.

I’ve used GitHub Actions:

To greet the contributor when they create their first issue on my project.
To add labels to the issues and pull requests created.
To validate the PRs, ensuring they’ve filled in all the necessary details in the PR template.

These are just simple tasks, but you’ll save so much time automating them using GitHub Actions.

You can use GitHub Actions to check if code changes work properly or if they break the website—and so much more.

If you feel too lazy to create a GitHub action from scratch, the GitHub Marketplace has thousands of GitHub actions ready to use.

Here are some examples of the GitHub Actions workflows that I used:

The below workflow file is what I used for greeting the contributors.

The below workflow file is what I used for labelling the issues and PRs.

The below workflow file is what I used for validating the PRs.

GitHub Actions is a game-changer for automating workflows and simplifying CI/CD.

Whether you're managing an open-source project or streamlining deployments, it saves time and effort.

Have you tried GitHub Actions in your projects? Let me know how it's helped you or what you're looking to automate next!

Coder Legion - Recent posts tagged github-actions

Segurança em CI/CD: a importância de estudar, auditar e aprender com pipelines de bons projetos

1. Por que estudar pipelines é tão importante?

2. Utilize scanners, mas não terceirize o julgamento técnico

Exemplo: template injection

3. Aprenda a diferenciar vulnerabilidades reais de findings parcialmente mitigados

4. Estude como projetos maduros resolvem problemas de segurança

5. Construa uma rotina de auditoria de pipelines

6. Crie um laboratório utilizando projetos reais

Conclusão

Automated PR Reviews with Cline and NVIDIA NIM APIs

Why Automated PR Review?

Architecture

Step-by-Step Setup

1. Add the secret

2. Write the workflow file

The 6 Problems I Hit (and how I fixed them)

1. Node 20 deprecation

2. unknown option '--base-url'

3. auth quick setup requires --modelid

4. 429 Too Many Requests (rate limit)

5. unknown flag: --stat

6. Retries duplicate findings

How We Pick the Dynamic Line Limit

Result: A Real PR Review

Real Example: TaxCalculator Refactor (PR #13)

PR Review — eraydiler/TaxCalculator#13

🔴 Blocking — Privacy: zero-data-retention claim is violated

🟡 Logic / Security

🟡 Tests

🟢 Minor / Style

✅ Looks good

Lessons Learned

Who Can Change Your npm Release Tags?

Who Should Be Allowed to Change Your npm Release Tags?

Why this matters

What development teams should review

Discussion

# The Revolution in Protocol Security: How It Actually Gets Used

The problem with existing tools is not only capability - it is also access

CI/CD integration: verify on every commit

IDE integration: find vulnerabilities while you write

Real-time analysis: the daemon and the sniffer

Web interface: collaboration, not just output

Converters: meeting people where they are

Platform, not tool

The revolution is practical, not technical

Status

Automatically update GitHub Action versions

Get Dependabot to do the work

Automatic pull requests

Setting GitHub as a trusted publisher for npm

Set the trusted publisher on npm

Check you GitHub Action

Stop Rewriting CI/CD: Reusable GitHub Actions for Maven Projects

Stop Rewriting CI/CD Pipelines for Every Maven Project

The Real Problem

A Different Approach

What NERV-Actions Is

Why This Matters

Design Philosophy

Example Use Case

Why Not Just Copy-Paste?

Still Evolving

Curious About Your Setup

Weather Service Project (Part 1): Building the Data Collector (Python, GitHub Actions or Netlify)

The First Step: Talking to the OpenWeatherMap API

The "Database": Why CSV and Not SQL?

The Automation Robot: GitHub Actions to the Rescue

Security First: Never Upload Your API Key!

The Robot's Brain: The .github/workflows/update-weather.yml File

The Serverless Alternative: Deployment and Automation with Netlify

Deploying the Static Frontend with Netlify

Automating the Backend with Netlify Functions (and Cron Jobs)

The Scaling Problem (and the Necessary Architectural Pivot)

Conclusion (Part 1)

References and Links of Interest:

Hello World to GitHub Actions: Your First Automated Workflow

What's GitHub Actions Anyway?

The Basics (Don't Worry, It's Simple!)

2. `unknown option '--base-url'`

3. `auth quick setup requires --modelid`

4. `429 Too Many Requests` (rate limit)

5. `unknown flag: --stat`

The Robot's Brain: The `.github/workflows/update-weather.yml` File