chore(ci): remove dead .gitlab-ci file

[darccio]

Summary

• Removes the tracked .gitlab-ci file (no extension), which sat alongside the real .gitlab-ci.yml and defined a copy_to_s3 deploy job.
• Removes the now-orphaned /.gitlab-ci entry from CODEOWNERS.

Why

GitLab only reads .gitlab-ci.yml (or a path configured per-project in the GitLab UI). Investigation showed .gitlab-ci is dead config:

• .gitlab-ci.yml's include: block (6 sources: benchmarks macro/micro/test-apps, docker-images-reliability-env, configuration-central-validation, and the remote apm-sdks-benchmarks project) never references .gitlab-ci.
• A repo-wide grep for the literal string .gitlab-ci (excluding .gitlab-ci.yml matches) only found the file's own CODEOWNERS entry — no include, script, or doc references it or the copy_to_s3 job / s3://datadog-reliability-env/go/index.txt artifact it produces.
• It was added standalone in 2020 (.gitlab-ci: add deploy job #682), before today's fully-wired .gitlab-ci.yml existed.
• Its only later edit (chore(ci): Migrate deprecated GitLab runner tags #4571, "Migrate deprecated GitLab runner tags") was an automated bot doing a mechanical, repo-wide tag substitution across every CI-shaped file it found — not a human deliberately verifying this specific job still runs. That's why it looked maintained without anyone having confirmed it's actually live.

I could not check the GitLab project's UI-configured CI-config-path setting directly, but all in-repo evidence points to this being an orphaned leftover from before the current GitLab CI setup, rather than a live custom-path config.

Test plan

• Confirmed no include: directive in .gitlab-ci.yml or .gitlab/ references .gitlab-ci
• Confirmed no other file in the repo references the literal string .gitlab-ci (excluding .gitlab-ci.yml)
• git status clean after removal; CODEOWNERS entry for the deleted file removed to avoid an orphaned rule

[datadog-datadog-prod-us1]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 64.97% (-3.98%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 117a7a8 | Docs | View more details | Give us feedback!}

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-08-21 10:48:43

Comparing candidate commit 117a7a8 in PR branch dario.castane/charming-goldwasser-af3699 with baseline commit 3028fed in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 335 metrics, 0 unstable metrics, 1 flaky benchmarks without significant changes.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

• 🟩 = significantly better candidate vs. baseline
• 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

Known flaky benchmarks

These benchmarks are marked as flaky and will not trigger a failure. Modify FLAKY_BENCHMARKS_REGEX to control which benchmarks are marked as flaky.

Known flaky benchmarks without significant changes:

• scenario:BenchmarkOTLPTraceWriterFlush