Skip to content

prepare v1.0.0 - #58

Merged
davgordo merged 2 commits into
mainfrom
release-v1.0.0
Aug 14, 2026
Merged

prepare v1.0.0#58
davgordo merged 2 commits into
mainfrom
release-v1.0.0

Conversation

@davgordo

Copy link
Copy Markdown
Contributor

No description provided.

@davgordo
davgordo merged commit 8ae6844 into main Aug 14, 2026
1 check passed

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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]}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge 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 👍 / 👎.

Comment on lines +112 to +115
providers:
github:
app: ${GITHUB_APP_ID}
catalogPath: /catalog-info.yaml

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge 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 👍 / 👎.

Comment on lines +23 to +24
- repoURL: https://github.com/contract-first-idp-test/platform-components.git
targetRevision: main

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge 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 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant