prepare v1.0.0 - #58
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 57a535ce57
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
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".
| apiVersion: generators.external-secrets.io/v1alpha1 | ||
| kind: Password | ||
| metadata: {name: backstage-backend, namespace: cf-idp-secrets} | ||
| spec: {length: 48, digits: 8, symbols: 0, noUpper: false, allowRepeat: true, secretKeys: [BACKSTAGE_BACKEND_SECRET]} |
There was a problem hiding this comment.
Map generated passwords to the keys consumers request
The External Secrets Password generator emits a password key; secretKeys is not part of its generator spec and therefore does not rename the output. Since every dataFrom entry consequently merges the same password key, platform-generated-secrets lacks BACKSTAGE_BACKEND_SECRET, KEYCLOAK_BACKSTAGE_CLIENT_SECRET, QUAY_ADMIN_PASSWORD, and the other properties referenced by downstream ExternalSecrets, preventing the default platform services from obtaining their credentials. Map each generator's password output explicitly to the required target key instead.
Useful? React with 👍 / 👎.
| providers: | ||
| github: | ||
| app: ${GITHUB_APP_ID} | ||
| catalogPath: /catalog-info.yaml |
There was a problem hiding this comment.
Nest the GitHub catalog provider under a provider ID
With the GitHub catalog backend module enabled, catalog.providers.github is keyed by provider IDs whose values are provider configuration objects. Here app is a scalar and catalogPath, filters, and schedule are its siblings, so they are interpreted as separate provider entries rather than one provider; the required organization configuration is also absent. The module therefore cannot initialize repository discovery for the documented Developer Hub deployment.
Useful? React with 👍 / 👎.
| - repoURL: https://github.com/contract-first-idp-test/platform-components.git | ||
| targetRevision: main |
There was a problem hiding this comment.
Point tenant values at the configured platform fork
When the documented installer runs configure-workshop.sh from any fork other than contract-first-idp-test, this source remains pinned to the original repository's main. Consequently $platform/catalog-info.yaml supplies the original target's cluster URLs and repository coordinates to the customer-experience chart instead of the generated fork-specific catalog, so the admitted Domain renders against the wrong target. The configuration flow must update this source and the matching AppProject allowlist to the configured platform repository and revision.
Useful? React with 👍 / 👎.
No description provided.