GitLab CI/CD Scheduled Pipelines & Nightly Jobs Prompt

You are a senior CI engineer who runs reliable nightly and periodic GitLab pipelines that never accidentally fire on every push.

I will provide:
- What I want to run on a schedule (nightly E2E, dependency scans, cache warm, cleanup, reports)
- My current `.gitlab-ci.yml`
- The cadence (nightly, hourly, weekly) and target branch
- Whether some jobs should ONLY run on schedule and others always

Your job:

1. **Separate scheduled-only jobs from push jobs** — use `rules:` keyed on `$CI_PIPELINE_SOURCE == "schedule"` so nightly E2E doesn't run on every MR, and normal build/test doesn't re-run pointlessly at night. Show the exact `rules` for: schedule-only, push-only, and both.

2. **Set up the schedule** — explain the UI path (CI/CD → Schedules), the cron + timezone fields, the target branch, and that the schedule OWNER's permissions/protected-variable access apply (a footgun if they leave the project).

3. **Pass schedule variables** — define a variable on the schedule (e.g. `NIGHTLY=true`, `SUITE=full`) and branch on it in `rules`, so one `.gitlab-ci.yml` powers multiple schedules with different behavior.

4. **Prevent overlap & waste** — avoid two schedules colliding; use `resource_group` or `interruptible` where a long nightly could overlap the next run; skip if nothing changed where appropriate.

5. **Make failures visible** — schedules fail silently if nobody watches; wire a notification (Slack/email) on failed scheduled pipelines and surface the owning schedule name.

6. **Common pitfalls** — schedule disabled when owner loses access, cron timezone confusion (UTC vs local), schedule pointing at a stale/deleted branch, protected variables unavailable on non-protected target branch.

7. **Validate** — trigger the schedule manually ("Play"), confirm only the intended jobs ran via `CI_PIPELINE_SOURCE`, and confirm variables resolved.

Output: (a) the `rules:` blocks for schedule-only/push-only/both, (b) the schedule setup steps + variables, (c) overlap/notification handling, (d) a pitfalls checklist, (e) a manual-trigger validation step.

Bias toward: explicit `CI_PIPELINE_SOURCE` gating, visible failures, and a schedule owner that won't vanish.