{
  "version": "2",
  "id": "https://freelancenews.online/news/developer-documents-first-gitlab-contribution-a-fillfactor-migration-981136f5",
  "title": "Developer Documents First GitLab Contribution: A Fillfactor Migration for Two Vulnerability Tables",
  "summary": "A community contributor describes opening merge request !260121 against GitLab to set fillfactor=90 on two vulnerability identifier tables, and reports that the initial CI pipeline failed with an unrelated shell error rather than a database problem.",
  "body": "A developer writing on dev.to has published a first-person account of making a first contribution to the GitLab codebase, describing the path from selecting an issue through opening a merge request. The post is a community write-up rather than an official GitLab announcement, so every detail below is the author's own account and has not been independently verified.\n\nAccording to the author, the work began with a search through GitLab issues flagged as suitable for community contribution. The issue chosen was #629994, titled \"Lower fillfactor on the vulnerability identifier tables,\" which concerned two tables: vulnerability_identifiers and vulnerability_occurrence_identifiers.\n\nThe author states that the issue included measurements showing relatively low HOT-update fractions for those tables, and that this was the motivation for the change. The reported figures were approximately 32.0 percent for vulnerability_identifiers and 64.2 percent for vulnerability_occurrence_identifiers. The author presents these numbers as coming from the issue, not from independent measurement.\n\nHow the request works at the PostgreSQL level is explained in the post. Rows of a table are kept by PostgreSQL within data pages, and the degree to which a page is targeted for filling at table creation or rewrite time is governed by the fillfactor storage parameter. When frequent updates affect a table, more space for placing a new row version on that same page is available to PostgreSQL if free space is left on each page.\n\nHeap-Only Tuple updates are tied to that. According to the author, when the updated row remains on the same heap page and no new index entries are needed for the indexed columns, new index entries can be avoided by a HOT update, and index-related work during updates may thereby be reduced. A fillfactor of 90 was the target requested in the issue.\n\nThe implementation itself was deliberately small. The author created a post-deployment database migration using GitLab's migration framework, applying fillfactor=90 to both tables. The migration is marked with milestone '19.5' and defines both up and down methods, so the setting can be applied and reverted. The up method runs ALTER TABLE statements setting fillfactor=90 on each table; the down method resets the fillfactor on each.\n\nThe author notes that the migration can be validated by running bin/rake db:migrate:up with the version 20261006165253, after which the resulting PostgreSQL table options can be inspected to confirm the fillfactor was set correctly.\n\nA significant part of the account concerns GitLab's contribution workflow for people outside the organisation. The author says GitLab provides a Community Fork workflow, and that they created a branch named 629994-lower-fillfactor-on-vulnerability-identifiers and pushed it to the GitLab Community Fork before opening a merge request against the main repository.\n\nThe merge request is identified in the post as !260121, titled \"db: lower fillfactor on vulnerability identifier tables to 90,\" and was linked to issue #629994 so the relationship between implementation and original issue was clear. The author also says the merge request included instructions for validating the migration.\n\nThe most instructive section of the post covers what happened after the merge request was opened. GitLab automatically started CI pipelines to validate the contribution, and the author reports that the initial pipeline contained failures across several different jobs.\n\nThe author says, crucially, that the same shell error was shown by multiple unrelated jobs: \"pop_var_context: head of shell_variables not a function context.\" Database setup jobs, migration-validation jobs, and other CI jobs all displayed that error. According to the author, no PostgreSQL error specifically tied to the migration, the two vulnerability tables, or the fillfactor setting was visible in the available logs.\n\nFrom this, a general lesson is drawn by the author: contributed code is not automatically wrong just because a CI pipeline fails, and investigating the actual failure, rather than immediately changing working code, was the appropriate response. This interpretation comes from the author's own experience; it is not a verified diagnosis of the pipeline failure.\n\nThe post closes with a set of takeaways the author says they would not have gained from solving coding problems locally: read the issue before writing code, understand the technology behind the change, learn the project's established workflows, investigate CI failures rather than assuming the code is at fault, and accept that small changes can still require careful reasoning because database storage behaviour can have performance implications at scale.\n\nFor freelancers and developers who work on client codebases or contribute to upstream projects, the account is a concrete illustration of how much of a contribution sits outside the diff. The Ruby migration is a few lines; the surrounding work involved reading issue context, understanding PostgreSQL page storage, following a fork-and-merge-request convention, and interpreting CI output. That ratio is worth budgeting for when scoping open-source work or estimating a client task that touches a large, unfamiliar repository.\n\nThere are also tradeoffs visible in the account. Lowering fillfactor to 90 leaves more free space per page, which the author frames as helpful for frequently updated tables, but the post does not discuss the cost side in any detail, such as additional pages and storage for the same row count. The author does not present any before-and-after performance measurement of their own, so the expected benefit rests on the issue's reported HOT-update fractions rather than on results from this change.\n\nSeveral things remain unknown. The author states that at the time of writing the merge request was still going through GitLab's normal review and CI process, so there is no confirmed outcome, no merge, and no release in which the change would appear. The cause of the shell error in the pipeline is not identified in the post. The author also does not say whether the CI failures were later resolved or whether the migration was revised.\n\nThe account should be read as one contributor's experience report. The issue number, merge request number, branch name, migration version and HOT-update percentages are all as stated by the author; none of them are corroborated by a second source in the supplied material, and the linked references do not independently support the same claims.\n\nThe practical value for this audience is procedural rather than technical novelty. The post documents a repeatable sequence for a first contribution to a large project: pick a well-defined issue, learn the project's contribution workflow, keep the change small, provide validation instructions in the merge request, and treat a red pipeline as a question to investigate rather than a verdict. The author's own summary is that the first contribution is the hardest part and that the process becomes more familiar afterwards.",
  "category": "dev",
  "language": "en",
  "datePublished": "2026-10-07T02:17:18.186Z",
  "dateModified": "2026-10-07T02:17:18.186Z",
  "eventDate": null,
  "sourcePublicationDate": "2026-10-07T01:49:59.000Z",
  "source": {
    "name": "dev.to",
    "url": "https://dev.to/kittu181707/my-first-gitlab-open-source-contribution-from-issue-to-merge-request-1k14",
    "kind": "community"
  },
  "practicalImpact": "Editorial interpretation: for freelancers and developers contributing to or maintaining large codebases, this account suggests budgeting time for issue reading, workflow conventions and CI triage, not just the code change. A few-line migration can still require understanding storage parameters and interpreting pipeline output, and a failing pipeline should be diagnosed before the working change is altered.",
  "limitations": "This is a single contributor's community post, not an official GitLab announcement, and none of its specifics are independently corroborated in the supplied evidence. The merge request was still in review and CI at the time of writing, so there is no confirmed merge, release or measured performance outcome. The cause of the reported CI shell error is not identified, and the post does not quantify the storage or page-count cost of lowering fillfactor to 90.",
  "keyPoints": [
    "A community contributor describes opening GitLab merge request !260121 to set fillfactor=90 on the vulnerability_identifiers and vulnerability_occurrence_identifiers tables, linked to issue #629994.",
    "The author reports the issue cited HOT-update fractions of roughly 32.0 percent and 64.2 percent for the two tables as motivation for the change, but presents no independent measurement of the effect.",
    "The change is a post-deployment migration marked milestone '19.5' with up and down methods, validated by running bin/rake db:migrate:up with version 20261006165253.",
    "The author says the initial CI pipeline failed across several jobs with the shell error \"pop_var_context: head of shell_variables not a function context,\" with no PostgreSQL error tied to the migration visible in the logs.",
    "At the time of writing the merge request was still in review and CI, so no merge, release or confirmed outcome is reported."
  ],
  "review": {
    "status": "source-reviewed",
    "checkedAt": "2026-10-07T02:17:18.186Z",
    "method": "Automated comparison against retrieved source text; not independent fact-checking.",
    "correctionNote": null
  },
  "sources": [
    {
      "id": 1,
      "url": "https://dev.to/kittu181707/my-first-gitlab-open-source-contribution-from-issue-to-merge-request-1k14",
      "publisher": "dev.to",
      "title": "My First GitLab Open Source Contribution: From Issue to Merge Request",
      "publishedAt": 1791337799000,
      "fetchedAt": 1791339421703,
      "hash": "1882d2e371c93b922b49bec9548a88da53a96cbcd5b99b86d1d7b33ee0f12d96",
      "kind": "community"
    }
  ],
  "claims": [
    {
      "claim": "The author selected GitLab issue #629994, titled \"Lower fillfactor on the vulnerability identifier tables,\" covering the vulnerability_identifiers and vulnerability_occurrence_identifiers tables.",
      "source": 1,
      "id": "claim-1",
      "url": "https://freelancenews.online/news/developer-documents-first-gitlab-contribution-a-fillfactor-migration-981136f5#claim-1"
    },
    {
      "claim": "The issue reported HOT-update fractions of approximately 32.0 percent for vulnerability_identifiers and 64.2 percent for vulnerability_occurrence_identifiers.",
      "source": 1,
      "id": "claim-2",
      "url": "https://freelancenews.online/news/developer-documents-first-gitlab-contribution-a-fillfactor-migration-981136f5#claim-2"
    },
    {
      "claim": "The migration applies fillfactor=90 to both tables and includes up and down methods, with the down method resetting the fillfactor.",
      "source": 1,
      "id": "claim-3",
      "url": "https://freelancenews.online/news/developer-documents-first-gitlab-contribution-a-fillfactor-migration-981136f5#claim-3"
    },
    {
      "claim": "The author opened merge request !260121, titled \"db: lower fillfactor on vulnerability identifier tables to 90,\" and linked it to issue #629994.",
      "source": 1,
      "id": "claim-4",
      "url": "https://freelancenews.online/news/developer-documents-first-gitlab-contribution-a-fillfactor-migration-981136f5#claim-4"
    },
    {
      "claim": "The initial CI pipeline failed across several jobs with the shell error \"pop_var_context: head of shell_variables not a function context,\" and the logs showed no PostgreSQL error specific to the migration or fillfactor setting.",
      "source": 1,
      "id": "claim-5",
      "url": "https://freelancenews.online/news/developer-documents-first-gitlab-contribution-a-fillfactor-migration-981136f5#claim-5"
    },
    {
      "claim": "At the time of writing, the merge request was still going through GitLab's normal review and CI process.",
      "source": 1,
      "id": "claim-6",
      "url": "https://freelancenews.online/news/developer-documents-first-gitlab-contribution-a-fillfactor-migration-981136f5#claim-6"
    }
  ],
  "formats": {
    "html": "https://freelancenews.online/news/developer-documents-first-gitlab-contribution-a-fillfactor-migration-981136f5",
    "markdown": "https://freelancenews.online/news/developer-documents-first-gitlab-contribution-a-fillfactor-migration-981136f5.md",
    "json": "https://freelancenews.online/news/developer-documents-first-gitlab-contribution-a-fillfactor-migration-981136f5.json"
  }
}