feat(eks-ci): declare the GitHub Actions OIDC identity provider#3
Conversation
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 57 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughAdds Kustomize manifests for a GitHub Actions AWS OIDC provider, CI workflows that render and aggregate manifest validation, release automation using semantic-release, and tag-triggered signed OCI manifest publication. It also adds repository guidance covering maintenance, authentication boundaries, CI, and signing, plus the Apache License 2.0. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
Re-lands #2 (which was accidentally based on the stale scaffold branch rather than main) as a clean commit on top of main. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
devantler
force-pushed
the
claude/eks-ci-github-oidc-provider-reland
branch
from
5ff59b1 to
dbbd746
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.releaserc:
- Around line 5-14: The `.releaserc` plugins configuration replaces
semantic-release’s defaults with only `@semantic-release/commit-analyzer`.
Update the `plugins` array to retain the default commit analyzer, release notes
generator, npm publisher, and GitHub publisher while preserving the custom
revert patch rule, using the existing semantic-release plugin configuration as
the reference.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: ffeff6b8-8f32-4b75-aa5d-5018bacd715f
📒 Files selected for processing (9)
.github/workflows/cd.yaml.github/workflows/ci.yaml.github/workflows/release.yaml.releasercAGENTS.mdLICENSEdeploy/eks-ci/github-oidc-provider.yamldeploy/eks-ci/kustomization.yamldeploy/kustomization.yaml
📜 Review details
🧰 Additional context used
📓 Path-based instructions (2)
**/*
📄 CodeRabbit inference engine (AGENTS.md)
Do not hand-edit generated files.
Files:
LICENSEAGENTS.mddeploy/eks-ci/kustomization.yamldeploy/kustomization.yamldeploy/eks-ci/github-oidc-provider.yaml
deploy/**/*.{yaml,yml}
📄 CodeRabbit inference engine (AGENTS.md)
deploy/**/*.{yaml,yml}: Validate every change before creating a PR withkubectl kustomize deploy/ > /dev/null; Crossplane CRD semantics are validated on-cluster.
Keep all managed resources underdeploy/and reference them fromdeploy/kustomization.yaml.
Keep manifests namespace-agnostic; the platform-side tenant Kustomization injects the namespace.
Do not add credentials or provider configuration; authentication wiring is handled platform-side, including the namespace,SecretStore, bootstrap-credentialExternalSecret, andProviderConfig.
Files:
deploy/eks-ci/kustomization.yamldeploy/kustomization.yamldeploy/eks-ci/github-oidc-provider.yaml
🧠 Learnings (1)
📓 Common learnings
Learnt from: CR
Repo: devantler-tech/aws
Timestamp: 2026-07-10T16:35:56.463Z
Learning: Never commit secrets; AWS credentials must come from OpenBao through the platform, and credential-shaped values in manifests are bugs.
Learnt from: CR
Repo: devantler-tech/aws
Timestamp: 2026-07-10T16:35:56.463Z
Learning: Fix root causes rather than applying superficial workarounds.
Learnt from: CR
Repo: devantler-tech/aws
Timestamp: 2026-07-10T16:35:56.463Z
Learning: Use Conventional-Commit PR titles and squash-merge changes; releases are cut by semantic-release on `main` pushes.
Learnt from: CR
Repo: devantler-tech/aws
Timestamp: 2026-07-10T16:35:56.463Z
Learning: Ensure the `CI - Required Checks` organization ruleset check passes.
Learnt from: CR
Repo: devantler-tech/aws
Timestamp: 2026-07-10T16:35:56.463Z
Learning: Preserve the release signing flow: the `v*` tag triggers `cd.yaml`, which publishes and cosign-signs the OCI artifact through the shared `publish-manifests.yaml` workflow; the platform verifier must match that workflow's signing identity.
🪛 LanguageTool
AGENTS.md
[uncategorized] ~15-~15: The official name of this software platform is spelled with a capital “H”.
Context: ...aws tenant reconciles. It mirrors the devantler-tech/.github repo's github-config tenant pattern....
(GITHUB)
🔇 Additional comments (8)
AGENTS.md (1)
1-34: LGTM!LICENSE (1)
1-202: LGTM!deploy/kustomization.yaml (1)
1-14: LGTM!deploy/eks-ci/kustomization.yaml (1)
1-25: LGTM!deploy/eks-ci/github-oidc-provider.yaml (1)
1-30: LGTM!.github/workflows/ci.yaml (1)
1-44: LGTM!.github/workflows/release.yaml (1)
1-19: LGTM!.github/workflows/cd.yaml (1)
1-38: LGTM!
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's internal server error or limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.releaserc:
- Around line 5-14: The `.releaserc` plugins configuration replaces
semantic-release’s defaults with only `@semantic-release/commit-analyzer`.
Update the `plugins` array to retain the default commit analyzer, release notes
generator, npm publisher, and GitHub publisher while preserving the custom
revert patch rule, using the existing semantic-release plugin configuration as
the reference.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: ffeff6b8-8f32-4b75-aa5d-5018bacd715f
📒 Files selected for processing (9)
.github/workflows/cd.yaml.github/workflows/ci.yaml.github/workflows/release.yaml.releasercAGENTS.mdLICENSEdeploy/eks-ci/github-oidc-provider.yamldeploy/eks-ci/kustomization.yamldeploy/kustomization.yaml
📜 Review details
🔇 Additional comments (8)
AGENTS.md (1)
1-34: LGTM!LICENSE (1)
1-202: LGTM!deploy/kustomization.yaml (1)
1-14: LGTM!deploy/eks-ci/kustomization.yaml (1)
1-25: LGTM!deploy/eks-ci/github-oidc-provider.yaml (1)
1-30: LGTM!.github/workflows/ci.yaml (1)
1-44: LGTM!.github/workflows/release.yaml (1)
1-19: LGTM!.github/workflows/cd.yaml (1)
1-38: LGTM!
🛑 Comments failed to post (1)
.releaserc (1)
5-14: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash set -euo pipefail printf '\n== files ==\n' git ls-files '.releaserc' '.github/workflows/*' | sed 's#^`#-` #' printf '\n== .releaserc ==\n' if [ -f .releaserc ]; then cat -n .releaserc fi printf '\n== workflow references ==\n' rg -n --hidden --glob '.github/workflows/*' 'create-release|semantic-release|release-notes-generator|`@semantic-release/github`|`@semantic-release/commit-analyzer`|plugins|extends|issues: write|pull-requests: write' .github/workflows .releaserc || trueRepository: devantler-tech/aws
Length of output: 980
🏁 Script executed:
#!/bin/bash set -euo pipefail printf '\n== release.yaml ==\n' cat -n .github/workflows/release.yaml printf '\n== cd.yaml ==\n' cat -n .github/workflows/cd.yamlRepository: devantler-tech/aws
Length of output: 2596
🌐 Web query:
devantler-tech/actions .github/workflows/create-release.yaml semantic-release plugins release-notes-generator github commit-analyzer💡 Result:
The file.github/workflows/create-release.yaml in the devantler-tech/actions repository is a reusable GitHub Actions workflow designed to automate releases using semantic-release [1][2]. Core Functionality and Configuration: - The workflow utilizes semantic-release to manage the release process, including versioning and changelog generation [1][2]. - Authentication for publishing releases is handled via a GitHub App. Callers are required to provide an APP_CLIENT_ID (as a repository or organization variable) and an APP_PRIVATE_KEY (as a secret) [1]. - The associated GitHub App requires specific permissions: contents: write (for tags and releases) and issues: write / pull-requests: write (for release comments) [1]. Regarding semantic-release plugins: - semantic-release relies on a plugin system to handle commit analysis and release note generation [3][4]. -
@semantic-release/commit-analyzer: This plugin is responsible for analyzing commit messages to determine the next release version (e.g., major, minor, patch) based on conventional commits [5]. -@semantic-release/release-notes-generator: This plugin generates the changelog content for the release based on the commits analyzed [6]. - These plugins, along with others like@semantic-release/npmand@semantic-release/github, are standard components of the semantic-release ecosystem [3][4]. They are configured within the semantic-release setup (typically via a.releaserc file or package.json) to execute in a specific order to automate the release lifecycle [3][4]. Context on the Repository: The devantler-tech/actions repository serves as a centralized location for DevantlerTech's CI/CD building blocks, including both composite actions and reusable workflows [2]. Note that reusable workflows previously located in the devantler-tech/reusable-workflows repository have been migrated to devantler-tech/actions [2].Citations:
- 1: https://github.com/devantler-tech/actions
- 2: https://github.com/devantler-tech/composite-actions
- 3: https://github.com/semantic-release/semantic-release/blob/HEAD/docs/usage/plugins.md
- 4: https://semantic-release.org/foundation/plugins/
- 5: https://github.com/semantic-release/commit-analyzer?tab=readme-ov-file
- 6: https://github.com/semantic-release/release-notes-generator
🌐 Web query:
site:github.com/devantler-tech/actions ".github/workflows/create-release.yaml" semantic-release plugins💡 Result:
The.github/workflows/create-release.yaml file is a reusable workflow pattern used to automate releases with semantic-release [1]. There is no single, mandatory set of plugins associated with this filename, as it represents a common pattern for implementing semantic-release within GitHub Actions rather than a standard configuration [1]. In professional workflows using this pattern, semantic-release typically relies on a standard set of plugins to interact with the GitHub ecosystem, which are configured in the repository's semantic-release settings (e.g.,.releaserc or package.json) rather than inside the workflow YAML file itself [1]. Common plugins used in these GitHub-based release workflows include: 1.
@semantic-release/commit-analyzer: Analyzes commits to determine the next version number based on commit types like feat, fix, or docs [2]. 2.@semantic-release/release-notes-generator: Automatically generates release notes based on the committed changes. 3.@semantic-release/github: Publishes the release to GitHub, updates tags, and can manage release comments on issues or pull requests [1]. To use such a workflow, callers typically pass necessary authentication credentials (such as an APP_PRIVATE_KEY) to enable the workflow to interact with the repository's contents and release metadata [1]. The workflow enforces semantic commit conventions, which are required for the automated versioning process to function correctly [2].Citations:
- 1: https://github.com/devantler-tech/actions
- 2: https://github.com/devantler-tech/actions/blob/main/AGENTS.md
🌐 Web query:
"devantler-tech/actions" "create-release.yaml" "@semantic-release/release-notes-generator" "@semantic-release/github" raw.githubusercontent.com💡 Result:
The devantler-tech/actions repository provides a reusable workflow named create-release.yaml that automates the release process using semantic-release [1][2]. This workflow is designed to streamline releases by integrating standard semantic-release plugins, specifically
@semantic-release/release-notes-generatorfor generating changelogs [3] and@semantic-release/githubfor publishing GitHub releases [4][5]. Key features and usage details for this reusable workflow include: 1. Authentication: The workflow utilizes a GitHub App token for publishing, which requires setting up an APP_CLIENT_ID (as a repository or organization variable) and an APP_PRIVATE_KEY (as a repository or organization secret) [1][2]. 2. Permissions: The GitHub App must have specific permissions granted: contents: write (to create tags and releases) and issues: write plus pull-requests: write (to add release comments) [1][2]. 3. Basic Usage: To use this workflow in your own repository, you reference it within a job in your GitHub Actions workflow file: jobs: release: uses: devantler-tech/actions/.github/workflows/create-release.yaml@{ref} secrets: APP_PRIVATE_KEY: ${{ secrets.APP_PRIVATE_KEY }} 4. Configuration Inputs: The workflow supports an optional dry-run input (boolean, defaults to false), which allows you to test the semantic-release process without actually creating tags or publishing releases [1][2]. By utilizing@semantic-release/release-notes-generatorand@semantic-release/github, this setup automates version determination, changelog generation, and GitHub release creation [6][7][8]. The use of raw.githubusercontent.com is typically involved when fetching these workflow files or configurations directly in a CI/CD pipeline context, though referencing the workflow via the uses syntax as shown above is the standard practice for GitHub Actions [1][2].Citations:
- 1: https://github.com/devantler-tech/actions
- 2: https://github.com/devantler-tech/composite-actions
- 3: https://github.com/semantic-release/release-notes-generator
- 4: https://semantic-release.gitbook.io/semantic-release/support/faq
- 5: https://github.com/semantic-release/github
- 6: https://github.com/semantic-release/semantic-release
- 7: https://svdoscience.com/2020-10-31/versioning-with-semantic-release
- 8: https://semantic-release.gitbook.io/semantic-release/recipes/ci-configurations/github-actions
🏁 Script executed:
#!/bin/bash set -euo pipefail for ref in v9.0.0 main; do echo "== $ref ==" url="https://raw.githubusercontent.com/devantler-tech/actions/${ref}/.github/workflows/create-release.yaml" if command -v curl >/dev/null 2>&1; then curl -fsSL "$url" | sed -n '1,220p' || true elif command -v wget >/dev/null 2>&1; then wget -qO- "$url" | sed -n '1,220p' || true fi echo doneRepository: devantler-tech/aws
Length of output: 3554
pluginsdrops the default release steps
create-release.yamljust runsnpx semantic-releaseand does not add any plugins back, so this.releasercleaves only@semantic-release/commit-analyzeractive. That means no release notes and no GitHub Release will be published."plugins": [ [ "`@semantic-release/commit-analyzer`", { "releaseRules": [ { "type": "revert", "release": "patch" } ] } - ] + ], + "`@semantic-release/release-notes-generator`", + "`@semantic-release/github`" ]📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements."plugins": [ [ "`@semantic-release/commit-analyzer`", { "releaseRules": [ { "type": "revert", "release": "patch" } ] } ], "`@semantic-release/release-notes-generator`", "`@semantic-release/github`" ]🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.releaserc around lines 5 - 14, The `.releaserc` plugins configuration replaces semantic-release’s defaults with only `@semantic-release/commit-analyzer`. Update the `plugins` array to retain the default commit analyzer, release notes generator, npm publisher, and GitHub publisher while preserving the custom revert patch rule, using the existing semantic-release plugin configuration as the reference.
@coderabbitai full review (The branch was rebuilt on top of |
🧩 Analysis chain🏁 Script executed: #!/bin/bash
gh pr view 3 --repo devantler-tech/aws --json title,body,baseRefName,headRefName,commits
echo "---DIFF---"
gh pr diff 3 --repo devantler-tech/aws --name-onlyLength of output: 1914
Kicking off a full review now. ✅ Action performedFull review finished. You're currently rate limited under our Fair Usage Limits Policy. Your next review will be available in 16 minutes. |
|
@codex review |
@codex review |
|
Codex Review: Didn't find any major issues. Breezy! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Promotion noted — this PR is CLEAN (green checks, 0 threads, pre-merge checks green) but my merge attempt was refused by the local permission layer this run. One-click: |
1 participant
Why
#2 was approved and merged, but it had accidentally been based on the leftover
claude/aws-config-tenant-scaffoldbranch instead ofmain— so the OIDC provider never reachedmain, no release was cut, and the manifest never reconciled onto the cluster (verified live: zeroOpenIDConnectProviderresources).What
Re-lands #2's exact commit onto
main(identical diff, no changes). Part of platform#2326. Once merged and released, the provider reconciles andstatus.atProvider.arnunblocks the step-2 CI Role.Operational note: after this merges I'll delete the stale scaffold branch so it can't catch another PR's base.