@dmakovey example pipeline: https://dev.gitlab.org/gitlab/omnibus-gitlab/-/pipelines/425571

The manifest-upload job runs a few stages prior to the check-packages-availability trigger job. This appears to become a blocking job, 😬

Could we add an empty needs that way there's no dependency on the pipeline stage?

Also question. I'm noticing this rule:

    - if: '$PIPELINE_TYPE =~ /_(RC|TAG)_BUILD_PIPELINE$/'
      when: manual

Is on this job. What plays those? I'm not aware of release-tools performing this action 🤔

John Skarbek (97fef25f) at 17 Mar 14:03

John Skarbek (cd06dda9) at 17 Mar 14:03

... and 1 more commit

Summary

Updates the security mirrors documentation to recommend the new YAML-driven Release Platform module as the preferred method for creating security mirrors.

Changes

• Added Release Platform module section as the preferred method for creating security mirrors
• Wrapped legacy Terraform instructions in a collapsible <details> block
• Added "Importing Existing Projects" section explaining current limitations
• Updated prerequisites to reference the new import section
• Added PSIRT approval to security mirror requirements

Why

The Release Platform module (work item #50) provides a standardized, YAML-driven way to provision the complete 3-mirror architecture with built-in integrations for common-ci-tasks, Vault, and more. This simplifies onboarding new projects and ensures consistent configuration.

References

• Release Platform module: https://gitlab.com/gitlab-com/gl-infra/terraform-modules/gitlab/release-platform
• Configuration file: https://gitlab.com/gitlab-com/gl-infra/infra-mgmt/-/blob/main/data/projects/release-platform/repos.yaml
• Related epic: gitlab-com/gl-infra/software-delivery#50

Ok, after a bit of research, I see no evidence that this is actually true 😒

@myacksmith I'm simply copying and pasting the work that you've done. Did you attempt apache style annotation at all? I'm willing to give this a shot. Curious your take prior to moving forward and accepting such suggestion.

John Skarbek (4a3f776d) at 16 Mar 20:03

John Skarbek (0a52bcf3) at 16 Mar 20:03

... and 1 more commit

What does this MR do?

This enables the Workhorse load shedding feature added in gitlab-org/gitlab!218865. In gprd, we use the following Prometheus query to determine that a backlog of 50-100 might be a reasonable threshold to start:

max by (pod) (
 max_over_time(puma_queued_connections{type="api"}[5m:15s])
)

In addition this enables NGINX to retry on 504 errors up to 3 times.

Relates to gitlab-com/gl-infra/production#21451

Author Check-list

Please read the Contributing document and once you do, complete the following:

• Check if all of the following apply:
  • Assign to the correct reviewer per the contributing document
  • Apply the correct metadata per the contributing document
  • Link to related MRs for applying the changes on other environments
  • Link to related Chef changes
  • If necessary link to a Criticality 4 Change Request issue

Reviewer Check-list

• Check if all of the following apply:
  • Reviewed the diff jobs to confirm changes are as expected
  • No changes shown in the diffs not associated with this MR - This may require a rebase or further investigation

Applier Check-list

• Make sure there is no ongoing deployment for the affected envs before merging (see #announcements slack channel)

This is ready for review!

Summary

Configure gunicorn_access_logformat for both API and Content pods in the pre environment to output structured JSON logs for better observability and log parsing.

Changes

• Added JSON access log format for API pods with fields: remote_ip, method, path, status, duration_us, correlation_id
• Added JSON access log format for Content pods with fields: remote_ip, request, status, duration_us, correlation_id

Why not workers?

Worker pods run Pulp's distributed task worker process (not gunicorn), so gunicorn_access_logformat is not applicable to them. Workers process asynchronous tasks from a queue, not HTTP requests.

Related

Relates to https://gitlab.com/gitlab-org/build/team-tasks/-/work_items/63