tre-troubleshooting
Skill237 starsChanged 38 days agoMITView on GitHub
Uses the exact commit, run attempt and component logs to separate observed causes from hypotheses. Use when you investigate a failed Azure TRE deployment, bundle operation or GitHub Actions run.
In this repository5 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .github/copilot-instructions.mdCopilot instructions
- tre-bundle-developmentSkill
- tre-code-reviewSkill
- tre-frontendSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 21
If the failed-job output is incomplete, inspect the relevant step and its preceding output in the full attempt logs.
- Distinctive: line 34
Use Application Insights queries, resource processor diagnostics, API logs
- Distinctive: line 36
Keep tokens, credentials and sensitive research data out of shared logs and reports.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Azure TRE troubleshooting
Identify the failing operation
Record the PR or branch, assessed head SHA, workflow run and attempt, failing job and step, and the relevant time window. For deployed failures, also identify the TRE, component or bundle version, resource ID and operation ID where available.
Distinguish the requested PR head from the commit actually checked out by the workflow. Inspect checkout steps, workflow inputs and logs; a run's headline SHA alone may not identify the deployed code.
For GitHub Actions, inspect a specific attempt with GitHub CLI when available:
gh run view <run-id> --repo microsoft/AzureTRE --attempt <attempt-number>
gh run view <run-id> --repo microsoft/AzureTRE --attempt <attempt-number> --log-failedIf the failed-job output is incomplete, inspect the relevant step and its preceding output in the full attempt logs. Do not combine failures from different attempts into one causal sequence.
Select the evidence source
| Failure stage | Evidence to inspect |
| Dependency, lint or unit-test failure | Exact command, runtime version, lockfile, full error and component test results |
| Management or core deployment | Terraform diagnostics, backend state/lock messages, workflow inputs and relevant Azure operation results |
| Bundle action | TRE operation status, resource processor logs, Porter action and underlying Terraform or script error |
| API request | Response status, resource/operation correlation and API traces |
| Airlock processing | Request stage, event/function logs and relevant storage operations |
| UI failure | Browser request and console evidence, user roles, workspace identity and component state |
Use Application Insights queries, resource processor diagnostics, API logs and Airlock diagnostics as appropriate.
Keep tokens, credentials and sensitive research data out of shared logs and reports. Capture the relevant diagnostic excerpt and correlation identifiers instead of copying an unrestricted log archive.
Isolate the cause
Find the earliest error that explains the failure. A later wrapper timeout or summary can hide the underlying Terraform, Azure or application error. Separate a failed deployment from tests that never ran, and separate cleanup failures from the original failure.
For each likely cause, state the supporting observation and the next check that would distinguish it from alternatives. Compare the tested commit, inputs and environment with a known working case where available. Treat quota, regional availability, permissions and retained Azure resources as hypotheses until verified.
Prefer read-only checks and a scoped local reproduction before changing infrastructure. Do not release a state lock, purge a resource, alter access or destroy an environment solely to clear an error. Those actions require an authorised recovery task and evidence identifying the affected environment and owner.
Report and follow up
State what failed, the observed cause or leading hypothesis, missing evidence and the next diagnostic step. Include the run attempt and commit with supporting links.
When a repair is authorised, use the component's procedure and verify the repaired path. Report the results according to the root reporting rules. Use the code-review skill for any PR test recommendation. A queued run, skipped job or manually successful check is not an executed test.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.