Rota Check Periodic Jobs
DevOps & Securityrota-check-periodic-jobsRota Check Periodic Jobs is an Agent Skill for devops & security published in the oracle/graalpython repository on GitHub: a SKILL.md instruction file an AI agent can load to do this task.
Analyze current GraalPy periodic job failures for ROTA. Use when asked to triage, summarize, or plan work for current periodic job failures, starting from scripts/rota_ci_failures.py output, validating linked Jira issues, inspecting logs, forming hypotheses, reproduction commands, and implementation order.
How to use this skill
Bring this guide into your coding agent with a prompt tailored to the tool you use.
- Open your project in Codex.
- Copy and paste the prompt below.
- Review files and risks before approving any action.
Inspect the Agent Skill at https://github.com/oracle/graalpython/blob/HEAD/.agents/skills/rota-check-periodic-jobs/SKILL.md and all supporting files. Report provenance, permissions, scripts, dependencies, and security risks. Propose an exact installation into .agents/skills/rota-check-periodic-jobs, but wait for my approval before writing files or running scripts.
Copying this prompt does not install or run the skill. Review third-party files before use.
ROTA Periodic Job Check
Overview
Triage current GraalPy periodic job failures and produce implementation-ready plans.
Workflow
- Verify dashboard environment and run the periodic failure collector:
- This workflow starts from
scripts/rota_ci_failures.py, not from a Jira search. - The script requires
OTDASHBOARD_URLandOTDASHBOARD_TOKEN. - If either variable is missing, stop and ask the user to set the missing variable(s). Do not fall back to querying Jira for the failure list.
- Run from the repository root:
scripts/rota_ci_failures.py
- Parse the script output:
- If it reports no failed jobs, report that there are no current failed periodic jobs and stop.
- For each failed row, capture target, job name, last successful run, Jira ID(s), and log URL.
- If a failed row has no Jira ID, flag it in the report and continue log analysis.
- Validate every reported Jira issue:
- Fetch each Jira issue linked by the script output:
gdev-cli jira get-issue --json -id GR-XXXX
- Check that the Jira matches the current failure:
- The issue summary or description should identify the same error signature/root cause from the current log.
- Check that the Jira is not too broad:
- A generic timeout/build-failure ticket is acceptable only if it names this job or an intentionally scoped equivalent set of jobs.
- A ticket covering unrelated jobs, unrelated targets, or unrelated error signatures is too broad.
- Check that the Jira has component
Python. - Notify the user about every Jira that fails any of these checks. Include the Jira key and the failed check(s).
- Inspect failed job logs:
- Use the
log URLfrom the script output. For Buildbot URLs, fetch the executor log with:
gdev-cli buildbot get-log BUILD_ID
- Use
gdev-cli buildbot rca --build BUILD_ID --waitwhen useful, but still inspect the relevant raw log lines. - Identify the exact failing command, error signature, first meaningful failure, and whether later errors are cleanup fallout.
- Convert findings into an implementation-ready plan per failure:
- Extract failing job name, error signature, and log clue.
- Map probable source area in repo.
- Propose the first verification command.
- Define exit criteria to close or update the linked ticket.
Output Contract
Group the output by the Jira issue. For each, report:
- The issue summary, status and assignee
- The failed jobs in a table with job name, last successful run and log URL.
- The analysis of the failure and the proposed plan
Guardrails
- If
OTDASHBOARD_URLorOTDASHBOARD_TOKENis missing, ask the user to set the missing variable(s). Do not try to set them yourself - Do not echo the
OTDASHBOARD_TOKENvariable and do not leak it anywhere. - Prefer
--jsonfor Jira issue fetches.