feat: handle pod annotations #278
Conversation
WalkthroughThe changes introduce new configuration options for specifying Kubernetes pod template annotations in both deployments and jobs. The documentation is updated to reference these new configuration keys. In the application resource logic, the deployment handling is refactored to use a series of modular mutator functions for clearer and more maintainable code. The logic for handling PodDisruptionBudgets (PDBs) is also restructured for improved clarity. For jobs, a new handler is added to apply pod template annotations from settings, extending the ability to customize job pods via configuration. Corresponding unit and integration tests are added to verify the correct application of annotations. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Settings
participant Application
participant Kubernetes
User->>Settings: Define pod template annotations in config
Application->>Settings: Retrieve annotations for deployment/job
Application->>Kubernetes: Apply annotations to pod templates (deployment/job)
Kubernetes-->>Application: Deploy resources with configured annotations
Poem
Tip ⚡💬 Agentic Chat (Pro Plan, General Availability)
📜 Recent review detailsConfiguration used: CodeRabbit UI ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (6)
🚧 Files skipped from review as they are similar to previous changes (5)
⏰ Context from checks skipped due to timeout of 90000ms (2)
🔇 Additional comments (4)
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
docs/09-Configuration reference/01-Settings.md (2)
35-35: Missing description cell for new keyPlease add a concise description so users know what the setting does, e.g.:
| deployments.`<deployment-name>`.spec.template.annotations | Map | firstAnnotation=X,anotherAnnotation=Y | Set Kubernetes pod‑template annotations for a specific deployment |
42-42: Typo / grammar
jobs'modules→jobs' modules(or simply “job modules”):-| Configure the annotations on specific jobs'modules +| Configure pod‑template annotations for specific job modules
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
docs/09-Configuration reference/01-Settings.md(1 hunks)internal/resources/applications/application.go(4 hunks)internal/resources/jobs/job.go(2 hunks)
| deployment.Spec.Selector = &metav1.LabelSelector{ | ||
| MatchLabels: deploymentLabels, | ||
| MatchLabels: labels, | ||
| } | ||
| deployment.Spec.Template.Labels = deploymentLabels | ||
| deployment.Spec.Template.Labels = labels | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Do not overwrite pre‑existing labels – merge instead
Assigning deployment.Spec.Template.Labels = labels discards any labels already present in the template copied from a.deploymentTpl (e.g. module, version, stack labels).
Safer approach: make sure the map exists and merge:
- deployment.Spec.Template.Labels = labels
+ if deployment.Spec.Template.Labels == nil {
+ deployment.Spec.Template.Labels = map[string]string{}
+ }
+ maps.Copy(deployment.Spec.Template.Labels, labels)Same for deployment.Spec.Selector.MatchLabels if additional selector labels may exist.
📝 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.
| deployment.Spec.Selector = &metav1.LabelSelector{ | |
| MatchLabels: deploymentLabels, | |
| MatchLabels: labels, | |
| } | |
| deployment.Spec.Template.Labels = deploymentLabels | |
| deployment.Spec.Template.Labels = labels | |
| deployment.Spec.Selector = &metav1.LabelSelector{ | |
| MatchLabels: labels, | |
| } | |
| if deployment.Spec.Template.Labels == nil { | |
| deployment.Spec.Template.Labels = map[string]string{} | |
| } | |
| maps.Copy(deployment.Spec.Template.Labels, labels) |
a010e9e to
c1fb772
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
internal/resources/applications/application_test.go (1)
46-46: Consider using descriptive test names instead of t.Name()Using
t.Name()as the test case name makes it difficult to distinguish between test cases in failure reports. Consider using descriptive names that indicate what each case is testing, such as "EmptyAnnotations" and "ExistingAnnotations".-t.Run(t.Name(), func(t *testing.T) { +t.Run(fmt.Sprintf("Case%d", i), func(t *testing.T) {Or even better:
-for _, tc := range []testCase{ +for i, tc := range []testCase{ // ... } // Then in the test: -t.Run(t.Name(), func(t *testing.T) { +testName := "WithExistingAnnotations" +if len(tc.deployment.Spec.Template.ObjectMeta.Annotations) == 0 { + testName = "WithEmptyAnnotations" +} +t.Run(testName, func(t *testing.T) {internal/tests/application_test.go (1)
27-27: Simple annotation key/value used for testingThe test uses a simple "annotations=annotations" key-value pair for testing. While this works for basic verification, consider testing with multiple annotation entries to ensure proper merging behavior, similar to how it's tested in the unit test.
-coresettings.New(uuid.NewString(), "deployments.*.spec.template.annotations", "annotations=annotations", stack.Name), +coresettings.New(uuid.NewString(), "deployments.*.spec.template.annotations", "annotation1=value1,annotation2=value2", stack.Name),
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
docs/09-Configuration reference/01-Settings.md(1 hunks)internal/resources/applications/application.go(4 hunks)internal/resources/applications/application_test.go(1 hunks)internal/resources/jobs/job.go(2 hunks)internal/tests/application_test.go(1 hunks)internal/tests/jobs_controller_test.go(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- docs/09-Configuration reference/01-Settings.md
- internal/resources/jobs/job.go
- internal/resources/applications/application.go
🧰 Additional context used
🧬 Code Graph Analysis (3)
internal/resources/applications/application_test.go (2)
internal/resources/applications/application.go (1)
Application(122-127)internal/core/utils.go (1)
WithAnnotations(93-106)
internal/tests/application_test.go (3)
api/formance.com/v1beta1/stack_types.go (2)
Stack(77-83)StackSpec(23-45)api/formance.com/v1beta1/ledger_types.go (2)
Ledger(97-103)LedgerSpec(55-68)api/formance.com/v1beta1/shared.go (1)
StackDependency(284-287)
internal/tests/jobs_controller_test.go (1)
api/formance.com/v1beta1/settings_types.go (2)
Settings(167-172)SettingsSpec(23-31)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Tests
🔇 Additional comments (5)
internal/resources/applications/application_test.go (1)
13-64: Well-structured unit test for WithAnnotations functionalityThe test thoroughly verifies that the WithAnnotations method correctly applies annotations to a Deployment's Pod template, covering both cases: when no annotations exist initially and when merging with existing annotations.
internal/tests/jobs_controller_test.go (2)
97-104: Good addition of settings for pod template annotationsThe settings entry for
jobs.*.spec.template.annotationswith a value of "first=second" is appropriately constructed to test the pod annotation functionality.
145-151: Well-implemented test for job annotationsThe test successfully verifies that annotations from settings are correctly applied to the job's pod template. The assertions check both that the annotations map exists and that it contains the expected key-value pair.
internal/tests/application_test.go (2)
14-61: Well-structured integration test for deployment annotationsThis test appropriately validates that annotations from settings are correctly applied to deployment pod templates. The test setup, execution, and cleanup are well-organized.
53-59: Good use of Eventually matcher for asynchronous verificationThe test correctly uses Gomega's Eventually matcher to handle the asynchronous nature of Kubernetes resource creation, which is important for reliable integration testing.
4ef0095 to
e1ce8bb
Compare
No description provided.