DEV Community: sai krishna chowdary

Navigating GitLab CI/CD on Forks: Lessons from Real Contributions

sai krishna chowdary — Sun, 11 Oct 2026 07:43:59 +0000

In my previous post, My First GitLab Open Source Contribution: From Issue to Merge Request, I shared my journey of opening and merging a database fix in the core gitlab-org/gitlab monolith.

Since having my first contributions merged—such as fixing the Contributor Analytics sidebar permission check (!260196)—I expanded my focus into GitLab's wider ecosystem. Over the past week, I actively authored contributions across satellite repositories, including the GitLab Development Kit (GDK), GitLab Shell, GitLab CLI (glab), GitLab Elasticsearch Indexer, Terraform Provider, and Dangerfiles.

Working across multiple distinct repositories quickly revealed a common hurdle for open-source contributors: writing the code fix is only half the process; understanding pipeline governance, fork isolation, and automated tooling is where real contributions succeed or stall.

Here are four real-world lessons and pipeline behaviors I encountered while submitting merge requests across the ecosystem.

1. The Fork Security Boundary

When contributing from a personal fork (your-username/project) targeting an upstream repository (gitlab-org/project), GitLab CI/CD runs within an intentional security boundary:

Contributor Fork: Runs on personal shared runners. For security, community fork pipelines cannot access upstream protected CI/CD variables or secrets.
Review Hand-Off: Assigning maintainers via @gitlab-bot ready queues the merge request for upstream review.
Upstream Project: Upstream runners execute the full compliance suite with access to internal bot tokens and maintainer approval gates.

The Masked Token Behavior

Several repositories use Dangerbot (danger-review) or automated labelers (autolabels). These utilities require GitLab API tokens (such as DANGER_GITLAB_API_TOKEN) to post automated comments.

Because forks do not inherit protected secrets, these jobs will fail on your fork runner. However, repositories configure these specific jobs with allow_failure: true. Recognizing that this failure is expected security isolation prevents unnecessary troubleshooting when your functional tests have already passed.

2. Reading the "Checks" Dashboard: Green Check vs. Orange Warning

In GitLab's merge request view, the Checks column displays status badges that often confuse first-time contributors:

Approval Count (0/1): Indicates human review status. Seeing 0/1 simply means the MR is waiting in the review queue for a project maintainer.
Green Checkmark (✓): Every pipeline job passed cleanly.
Orange Exclamation (!) ("Passed with warnings"): All compilation, build, unit test, and linting jobs passed, but an optional job marked allow_failure: true completed with a non-blocking warning.
Red Cross (✗): A mandatory blocking test, linter, or build failed and requires an update.

Key Takeaway: An orange (!) warning does not block merging. Once maintainers review and approve your code, they can merge the MR directly.

3. Real Engineering Quirks Encountered

A. The Scoped Label Permission Barrier

While contributing to gitlab-org/terraform-provider-gitlab (!3324), the pipeline failed on a label validation script:

// CI Job: validate:mr-labels
Checking MR for required type::* label...
ERROR: Merge Request must have at least one type::* label
       (e.g. type::maintenance, type::feature)

Attempting to apply the label via the CLI:

glab mr update 3324 \
  --add-label "type::maintenance"

Under GitLab's scoped labels architecture, modifying type::* labels requires Reporter+ project permissions. For community contributors, the API silently ignores the scoped label update.

The Solution: Do not try to force project permissions. Trigger Reviewer Roulette with @gitlab-bot ready, and leave a clear triage comment:

"Hi @reviewer! Community contributors cannot apply scoped group labels. Could you please apply ~type::maintenance and trigger the review pipeline? Thanks!"

B. Schema-Generated Documentation Mismatches

When updating documentation links in provider codebases, editing only the .md documentation file often causes the CI pipeline to fail:

=== RUN   TestGeneratedDocsUpToDate
    provider_test.go:42: documentation out of sync with schema
--- FAIL: TestGeneratedDocsUpToDate (0.12s)

Why this happens: In provider codebases like terraform-provider-gitlab (!3327), markdown documentation is generated from Go struct tags via tfplugindocs:

// internal/provider/datasource_gitlab_security_policy_document.go
"security_policy": schema.StringAttribute{
    MarkdownDescription: "Learn more at " +
      "https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/",
}

If you edit the generated markdown file without updating the Go source definition, the test detects the mismatch and fails.

The Fix: Always search the repository for occurrences of the string and update both the Go schema MarkdownDescription and the markdown file together.

C. Catching Silent 404s and Auth Redirects

Documentation maintenance often requires navigating platform migrations. While updating references in the GitLab Development Kit (!6249), legacy links to individual tracing and metrics guides redirected unexpectedly to internal sign-in pages (HTTP 403).

GitLab had consolidated standalone observability topics into a single GitLab Observability documentation guide.

The Lesson: Never assume an updated link works based on the path structure alone. Verify link health programmatically before pushing:

// Verify the target URL returns HTTP 200
curl -I -L -s -o /dev/null -w "%{http_code}\n" \
  https://docs.gitlab.com/operations/observability/observability/

4. Open Source Contributor Checklist

Here is the checklist I follow before marking any merge request ready for review:

[x] DCO Signed-off-by: Ensure commits include Signed-off-by: Name <email> (git commit -s) to satisfy the Developer Certificate of Origin.
[x] Link Health Verification: Test modified URLs with curl to confirm they return HTTP 200 without hitting authentication redirects.
[x] Atomic Commits: Keep changes focused on a single concern.
[x] Summon Reviewers: Use @gitlab-bot ready to engage Reviewer Roulette and notify the assigned maintainer.
[x] Clear Context: Summarize the change and explain why it improves the codebase.

Summary

Contributing to open source across multiple repositories provides firsthand insight into the automated workflows and governance that protect large-scale platforms like GitLab.

Every failed check, missing label, and schema mismatch is a practical lesson in how modern distributed codebases are validated, reviewed, and maintained.

Keep reading pipeline logs, keep asking questions in the review threads, and happy contributing! 🚀

My First GitLab Open Source Contribution: From Issue to Merge Request

sai krishna chowdary — Wed, 07 Oct 2026 01:49:59 +0000

My First GitLab Open Source Contribution: From Issue to Merge Request

Contributing to a large open-source project can feel intimidating when you are seeing the codebase for the first time. GitLab is a particularly interesting project to contribute to because it combines a large Ruby on Rails application with databases, CI/CD, frontend code, and many other components.

For my first GitLab contribution, I decided to work on a database-related issue involving PostgreSQL table storage and HOT updates.

This post describes what I learned while going from an issue to an actual merge request.

Finding a Contribution

I started by looking through GitLab issues that were suitable for a community contribution.

The issue I selected was #629994, "Lower fillfactor on the vulnerability identifier tables."

The issue concerned two tables:

vulnerability_identifiers
vulnerability_occurrence_identifiers

The issue included measurements showing relatively low HOT-update fractions for these tables. That made it a good opportunity to understand how PostgreSQL storage parameters can affect update behavior.

Understanding PostgreSQL Fillfactor

PostgreSQL stores table rows inside data pages. The fillfactor storage parameter controls how much of a table page PostgreSQL aims to fill when creating or rewriting the table.

For tables that are frequently updated, leaving some free space on a page can be useful because it gives PostgreSQL more room to place a new row version on the same page.

For this contribution, the requested target was a fillfactor of 90.

The migration therefore changes the storage parameter on both vulnerability identifier tables to fillfactor=90.

Why HOT Updates Matter

PostgreSQL supports Heap-Only Tuple (HOT) updates.

A HOT update can avoid creating new index entries when the updated row can remain on the same heap page and the indexed columns do not require new index entries.

This can reduce index-related work during updates.

The issue reported measured HOT-update fractions of approximately:

32.0% for vulnerability_identifiers
64.2% for vulnerability_occurrence_identifiers

These measurements provided the motivation for increasing the available free space on the pages by using a lower fillfactor.

Implementing the Change

The implementation was intentionally small.

I created a post-deployment database migration.

The migration uses GitLab's database migration framework and applies a fillfactor of 90 to both tables:

# frozen_string_literal: true

class LowerFillfactorOnVulnerabilityTables < Gitlab::Database::Migration[2.3]
  milestone '19.5'

  def up
    execute('ALTER TABLE vulnerability_identifiers SET (fillfactor=90)')
    execute('ALTER TABLE vulnerability_occurrence_identifiers SET (fillfactor=90)')
  end

  def down
    execute('ALTER TABLE vulnerability_identifiers RESET (fillfactor)')
    execute('ALTER TABLE vulnerability_occurrence_identifiers RESET (fillfactor)')
  end
end

The migration includes both up and down methods so that the setting can be applied and reverted.

One thing I learned from this contribution is that a small code change can still require understanding the surrounding database architecture and migration conventions of a large project.

Working With the GitLab Community Fork

Another part of the process was learning how GitLab handles contributions from external contributors.

GitLab provides a Community Fork workflow for contributors. I created my contribution branch:

629994-lower-fillfactor-on-vulnerability-identifiers

and pushed the branch to the GitLab Community Fork.

This was an important part of the experience because contributing to a large open-source repository is not only about writing code. Understanding the project's contribution workflow is equally important.

Creating the Merge Request

After pushing the branch, I opened a merge request against GitLab's main repository.

The merge request was:

!260121 — db: lower fillfactor on vulnerability identifier tables to 90

I linked the merge request to issue #629994 so that the relationship between the implementation and the original issue was clear.

The merge request also included instructions for validating the migration.

For example, the migration can be executed with:

bin/rake db:migrate:up VERSION=20261006165253

The resulting PostgreSQL table options can then be inspected to verify that the fillfactor has been set correctly.

The CI Experience

One of the biggest lessons came after opening the merge request.

GitLab automatically started CI pipelines to validate the contribution.

The initial pipeline contained failures across several different jobs. An important part of the investigation was that multiple unrelated jobs showed the same shell error:

pop_var_context: head of shell_variables not a function context

The error appeared in database setup and migration-validation jobs as well as other CI jobs.

The available logs did not show a PostgreSQL error related specifically to the migration, the two vulnerability tables, or the fillfactor setting.

This was a useful reminder that a failed CI pipeline does not automatically mean that the code being contributed is wrong.

The appropriate response was to investigate the actual failure rather than immediately changing working code.

What I Learned

This first contribution taught me several things that I would not have learned from simply solving coding problems locally.

1. Read the issue before writing code

The issue often contains important context about why a change is required.

In this case, the HOT-update measurements helped explain why changing the fillfactor was being considered.

2. Understand the technology behind the change

The migration itself was only a few lines of Ruby.

However, understanding PostgreSQL pages, fillfactor, and HOT updates made the change much easier to reason about.

3. Large open-source projects have established workflows

Branching, community forks, merge requests, labels, approvals, CI pipelines, and contribution rules are all part of the process.

Knowing the workflow is just as important as knowing Git.

4. CI failures need investigation

A red pipeline is not automatically proof of a bad implementation.

Looking at the actual failure messages and determining whether they are related to the changed code is an important part of software engineering.

5. Small changes can still require careful reasoning

The final migration is small, but database storage behavior can have performance implications at scale.

That is one of the things I find interesting about contributing to mature open-source projects: even a small change can require careful investigation.

What's Next

At the time of writing, the merge request is going through the normal GitLab review and CI process.

Regardless of the final outcome, the contribution has already given me practical experience with:

GitLab's contribution workflow
PostgreSQL storage parameters
Database migrations
HOT updates
Git branches and forks
Merge requests
CI troubleshooting
Open-source collaboration

This is my first contribution to the GitLab codebase, and I hope it will be the beginning of many more.

Conclusion

My biggest takeaway is that open-source contribution is not simply about finding a line of code to change.

It is about understanding the problem, researching the existing implementation, following the project's conventions, testing the change, communicating clearly, and working through review and CI.

For anyone making their first contribution to a large project, I would recommend starting with a well-defined issue, learning the project's contribution workflow, and not being afraid of a large codebase.

The first contribution is the hardest part. After that, the process starts becoming much more familiar.

Self-Hosting SigNoz with Foundry on Windows ARM64 (and the WSL2 wall that almost stopped me)

sai krishna chowdary — Fri, 17 Jul 2026 12:19:48 +0000

My laptop is a Windows ARM64 machine. Most self-hosted observability tooling assumes you're on Linux, macOS, or at worst regular x86 Windows — so when I sat down to self-host SigNoz for the Agents of SigNoz hackathon, I genuinely didn't know if it would work at all before I'd tried. An hour later I had a fully healthy stack, an MCP server responding, and one very specific error message that taught me something the docs don't spell out.

Why self-host, and why Foundry

I'm building an autonomous incident-response agent for this hackathon, and my first instinct was to reach for SigNoz Cloud — no infrastructure to babysit, one less thing to break mid-week. But the hackathon's own field requirements are specific: install via Foundry, and include the resulting casting.yaml/casting.yaml.lock in your repo so judges can reproduce the deployment. That's a self-hosted-only requirement — Foundry doesn't target Cloud at all. So before committing to that architecture for the real project, I wanted to know: does this actually work cleanly on my hardware, or am I about to spend Day 1 fighting Docker instead of building?

Getting Foundry running

Foundry is SigNoz's newer install path — it replaced the old install script, and the whole idea is config-as-code: one file describes your deployment, one command stands it up. The minimal casting.yaml is small enough to read in full:

yamlapiVersion: v1alpha1
kind: Installation
metadata:
name: signoz
spec:
deployment:
flavor: compose
mode: docker

Then:

bashfoundryctl cast -f casting.yaml

That single command checks your environment, generates the actual Compose files, and brings up ClickHouse, ClickHouse Keeper, Postgres, the OTel collector, and the SigNoz UI. Watching everything land on Healthy in one pass, on an ARM64 machine I half-expected to fight with, was a genuinely good moment.

The wall: "docker: command not found"

Everything worked — until I stopped the containers to test a clean restart, and came back to this:

The command 'docker' could not be found in this WSL 2 distro.
We recommend to activate the WSL integration in Docker Desktop settings.

This confused me for longer than I'd like to admit, because Docker had just worked, in the same terminal, minutes earlier. The actual cause: Docker Desktop's WSL integration isn't a single global switch — it's enabled per distro, individually, and I hadn't noticed my specific distro (Dicky) had its own toggle sitting separately in Docker Desktop → Settings → Resources → WSL Integration. Flipping that on and hitting Apply & Restart fixed it immediately.

The lesson that's easy to miss from the docs alone: "enable WSL integration" doesn't mean "flip it on once." If you're running multiple WSL distros, or reinstalled/renamed yours, check that your specific distro is checked, not just that integration is on in general.

Turning on the MCP server

The feature I actually wanted to test was SigNoz's own MCP (Model Context Protocol) server — since my hackathon project is an agent that needs to query telemetry programmatically, and SigNoz shipping this as a first-class, one-flag addition to Foundry is directly relevant. Adding it meant one small edit to casting.yaml:

yamlspec:
mcp:
spec:
enabled: true

Re-running foundryctl cast added the signoz-mcp container without disturbing anything already running — no downtime for the rest of the stack, which I wasn't expecting from a config-as-code tool on a first try. A health check confirmed it:

bashcurl -fsS localhost:8000/livez && echo " OK"

ok OK

That means any MCP-compatible client — Claude Code, Cursor, or the custom agent I'm building — can query real traces, logs, and metrics using the same schema a human sees in the UI, without a separate integration project. For a hackathon track built specifically around agent-native observability, that's a meaningfully lower barrier than I expected.

Setting up API access

Last piece: a Service Account, created under Settings → Identity & Access → Service Accounts (not the account dropdown at the top, which is just your personal profile — took me a minute to find the right menu). Generating a key from its Keys tab gave me the credential both the MCP server and SigNoz's regular query API use for programmatic access.

What I'd tell someone else trying this

If you're on Windows, check Docker Desktop's WSL integration toggle is on for your specific distro, not just enabled generally — this cost me the most confusion for the least actual problem.
The MCP flag costs nothing to enable up front, even if you're not sure yet whether you'll use it.
Foundry's pitch — one config file, one command, reproducible via casting.yaml.lock — held up under a genuinely awkward hardware combination (Windows, ARM64, WSL2). Total time from zero to a fully healthy stack, WSL hiccup included: under an hour.

Conclusion

Self-hosting SigNoz via Foundry on Windows ARM64 works, and works cleanly, once you know where the one Windows-specific gotcha is hiding. Next up: instrumenting real services with OpenTelemetry and building the actual incident-response agent this was all in service of.