Triage Stale GitLab Issues and Create a Weekly Report

Keep your GitLab backlog clean by automatically detecting stale issues that have gone untouched for too long and opening a single weekly triage report your team can act on. This flow searches every open issue in a GitLab project, filters the ones with no activity beyond a configurable threshold (default 30 days), and creates a tracking issue that lists each stale item with its link, last update, and labels. It turns backlog hygiene from a manual chore into a scheduled, repeatable orchestration covering GitLab issue search, stale detection, and automated issue creation.

How it works

1. A scheduled trigger weekly_triage (io.kestra.plugin.core.trigger.Schedule) fires every Monday at 9 AM UTC via the cron 0 9 * * 1.
2. search_open_issues (io.kestra.plugin.gitlab.issues.Search) fetches all issues in the state: opened for the configured projectId.
3. find_stale_issues (io.kestra.plugin.scripts.python.Script) loads the issues, compares each updated_at against a cutoff derived from the stale_days input, and writes the matches to stale_issues.json.
4. log_summary (io.kestra.plugin.core.log.Log) records the path to the generated stale report.
5. create_triage_issue (io.kestra.plugin.gitlab.issues.Create) opens a new GitLab issue titled with the run date, embeds the stale list, and applies the triage and stale labels.

What you get

• A weekly, dated triage issue summarizing every stale item in one place.
• A machine-readable stale_issues.json artifact for downstream use.
• A configurable staleness window via the stale_days input.
• Consistent labels (triage, stale) for easy filtering and reporting.

Who it's for

• Engineering managers and team leads keeping backlogs healthy.
• DevOps and platform teams standardizing issue hygiene across projects.
• Open source maintainers triaging community issues on a cadence.

Why orchestrate this with Kestra

GitLab has no native scheduler that can periodically scan issues, apply custom staleness logic, and open a summary issue. Kestra fills that gap: the event driven Schedule trigger runs the job on a precise cron, declarative YAML keeps the whole pipeline versioned and reviewable, retries handle transient API failures, and full execution lineage shows exactly which issues were flagged in each run. Mixing a Python filtering step with native GitLab tasks in one flow is something GitLab CI alone cannot express cleanly.

Prerequisites

• Access to GitLab (cloud or self-hosted) with a project you can read and create issues in.
• A Python script runner available to your Kestra instance.

Secrets

• GITLAB_TOKEN: a GitLab personal access token with api scope.
• PROJECT_ID: the numeric ID of your GitLab project (Settings, General).

Quick start

1. Create a GitLab personal access token with api scope.
2. Add it as a Kestra secret named GITLAB_TOKEN.
3. Add your project ID as the secret PROJECT_ID.
4. Create the triage and stale labels in your GitLab project.
5. Upload the flow and run it manually, or enable the weekly schedule.

How to extend

• Adjust stale_days per project to tighten or loosen the staleness window.
• Filter the search by labels, milestones, or assignees before triage.
• Add a notification task to post the report to Slack or email.
• Auto-close or auto-label issues that exceed a second, longer threshold.

Links

• GitLab plugin docs
• GitLab orchestration with Kestra