Claude finished @statik's task —— View job

PR Review: feat: add support for disabling Connect OAuth2.RegisterOnFirstLogin

Clean, well-structured addition that follows existing codebase patterns. Tests are thorough with good coverage of both the happy path and edge cases. A few observations:

api/core/v1beta1/connect_config.go:89 — gcfg serialization behavior

The RegisterOnFirstLogin bool field with omitempty JSON tag will always be serialized in gcfg output (even when false) because GenerateGcfg uses reflect.Value.String() which returns "<bool Value>" for bools — never empty. This is actually the desired behavior (explicit false in the config), but worth noting since the omitempty tag has no effect on gcfg output. Consistent with all other bool fields in this struct.

api/core/v1beta1/connect_types.go:132 — bool vs *bool trade-off

With bool + omitempty, there's no way to distinguish "explicitly set to false" from "not set" in the Kubernetes API. Since the default is false and Connect's upstream default is also false, this works today. If Connect's upstream default for RegisterOnFirstLogin ever changes to true, this operator would need a breaking API change to *bool. This matches the existing pattern for other bool fields (e.g. Debug), so it's consistent — just noting the trade-off.

internal/controller/core/connect.go:271-276 — Warning branches could be simplified

Suggestion: The two warning branches could be a single condition:

if c.Spec.RegisterOnFirstLogin && c.Spec.Auth.Type != positcov1beta1.AuthTypeOidc {
    l.Info("registerOnFirstLogin is set but auth type is not oidc; this setting only applies to OAuth2/OIDC and will be ignored",
        "authType", c.Spec.Auth.Type)
}

Logging "authType", "" for the empty-auth case is still accurate. Up to you whether the separate messages are worth the extra branch.

Missing: Site-level integration test

There are no tests in site_test.go verifying that InternalConnectSpec.RegisterOnFirstLogin flows through from the Site CR to the Connect CR via site_controller_connect.go:150. The existing Site tests don't cover this field. Consider adding a test to verify the Site→Connect propagation path.

Checklist

• Kubebuilder annotations correct — field has proper godoc comment
• New field has sensible default (false)
• CRDs are up to date (both config/crd/ and dist/chart/)
• Config flows from Site → Product correctly (site_controller_connect.go:150)
• Reconciliation is idempotent — bool assignment is deterministic
• Unit and integration tests exist for Connect reconciler
• Site-level integration test for propagation path (missing but non-blocking)

Note: I was unable to submit a formal GitHub review due to tool permissions — posting review feedback here instead.

@claude review this PR again

Claude finished @statik's task —— View job

PR Review: feat: add support for disabling Connect OAuth2.RegisterOnFirstLogin

• Read all changed files
• Review API type definitions
• Review controller logic and config generation
• Review tests
• Review CRD and client-go changes
• Post review feedback

This PR is clean and ready to merge. All observations from the previous review have been addressed — notably, site-level integration tests (TestSiteReconciler_RegisterOnFirstLoginPropagation and TestSiteReconciler_RegisterOnFirstLoginDefaultFalse in site_test.go:1024-1047) have been added. Here's the full re-review:

Summary

The implementation correctly adds RegisterOnFirstLogin as a bool field on ConnectSpec and InternalConnectSpec, wired through to the Connect gcfg [OAuth2] RegisterOnFirstLogin setting. The field only takes effect when auth type is OIDC — for other auth types, it's ignored with appropriate warnings.

Code Quality

• API types (connect_types.go:130-132, site_types.go:235-237): Field placement and godoc comments are correct. Consistent with existing bool fields like Debug.
• Config generation (connect_config.go:89): RegisterOnFirstLogin bool with omitempty JSON tag is consistent with other bool fields in ConnectOAuth2Config. The gcfg serializer writes false explicitly (via reflect.Value.String() always returning non-empty for bools), which is the desired behavior.
• Controller logic (connect.go:271-276): Warning logic correctly handles both empty auth type and non-OIDC auth type cases. The field is only wired to configCopy.OAuth2.RegisterOnFirstLogin inside the OIDC branch (connect.go:321), so it's never written to config for other auth types.
• Site propagation (site_controller_connect.go:150): RegisterOnFirstLogin: site.Spec.Connect.RegisterOnFirstLogin — simple and correct.
• client-go (connectoauth2config.go, connectspec.go, internalconnectspec.go): Generated code is correct and complete with With* builder methods.
• CRDs (core.posit.team_connects.yaml, core.posit.team_sites.yaml in both config/crd/ and dist/chart/): All four CRD files updated consistently.

Tests

• Unit test (connect_config_test.go:179-204): Covers both RegisterOnFirstLogin = true and default false gcfg serialization.
• OIDC integration tests (connect_test.go:338-411): TestConnectReconciler_OIDC_EnableRegisterOnFirstLogin and TestConnectReconciler_OIDC_DefaultRegisterOnFirstLogin verify the full reconciliation flow including configmap content assertions.
• Non-OIDC edge cases (connect_test.go:413-481): TestConnectReconciler_RegisterOnFirstLogin_IgnoredWithNoAuth and TestConnectReconciler_RegisterOnFirstLogin_IgnoredWithSAML verify the field doesn't bleed into config for other auth types.
• Site-level propagation (site_test.go:1024-1047): TestSiteReconciler_RegisterOnFirstLoginPropagation and TestSiteReconciler_RegisterOnFirstLoginDefaultFalse cover both true and default false paths from Site CR to Connect CR.

No Issues Found

The previous review's suggestion to simplify the two warning branches (connect.go:271-276) is a style preference — the current code is clear and the separate messages provide slightly more specific logging for the empty-auth case. Either approach is fine.

LGTM — this is a well-structured, backward-compatible addition with thorough test coverage across all layers (unit, integration, site propagation).

FWIW, I ran roborev GPT-5.2 Codex across four review turns as well as applying the claude code review suggestions.