mirror of
https://github.com/datadog-labs/agent-skills.git
synced 2026-09-14 19:03:36 +08:00
Teddy Kahwaji
157edafdc1
* Add dd-aws-integration skill Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Add dd-azure-integration skill Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Add dd-gcp-integration skill Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Add dd-oci-integration skill Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Correct the UK1 trusted account and the Terraform key-passing note UK1 is a real Datadog site with its own AWS trusted account, 117348461845 (verified against DdAccountIdBySite in DataDog/cloudformation-template). Folding it into the 464622532012 row writes an sts:AssumeRole trust for the wrong account, so a UK1 install collects nothing. The keys also never travel through TF_VAR_* here and nothing is declared ephemeral: the datadog provider reads DD_API_KEY / DD_APP_KEY from the environment. Leaving the stale note in can push a model into inventing key variables the template prohibits. * Correct the Terraform key-passing note The keys never travel through TF_VAR_* and nothing is declared ephemeral: the datadog provider reads DD_API_KEY / DD_APP_KEY from the environment. The client-secret caveat below the bullet is unchanged and still applies. * Fix the google_projects folder filter and the key-passing note data.google_projects calls Cloud Resource Manager v1, whose filter runs server-side and does not share the gcloud --filter grammar used during discovery: it has no AND/OR/NOT keywords, requires parent.type alongside parent.id, and has no projectId field. The old filter therefore fails with an invalid-filter error or mis-parses, so a folder-based install enables APIs on the wrong or empty project set and silently collects nothing. The sys-* exclusion has no valid v1 form and moves client-side into all_project_ids. The keys also never travel through TF_VAR_* and nothing is declared ephemeral: the datadog provider reads DD_API_KEY / DD_APP_KEY from the environment. * Honour the selected OCI profile and pin the module revision The credential and OCID checks read OCI_CLI_PROFILE and fell back to DEFAULT, so naming a profile in conversation was not enough: the checks inspected a different identity than the one being installed. Phase 1 now settles the profile up front and the oci CLI calls pass it explicitly. The module source also carried no ref, and Terraform's lock file does not lock remote module revisions, so every fresh init resolved whatever sat on the default branch. This module creates IAM users, policies, API keys and Vault resources, so pin it: datadog-integration-v1.1.17, which is byte-identical to master today. * Note OpenTofu as a drop-in substitute for Terraform Every command in the four cloud integration skills is written as `terraform`, so an agent working with a user who only has `tofu` installed fails at the first preflight check. Add a Phase 0 note to detect the binary and substitute throughout. The provider short-form sources and the OCI module's pinned GitHub source resolve identically under both, so no other change is needed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Ryan MacLean <6923433+ryanmaclean@users.noreply.github.com>