Skip to content

fix(backup): apply configured podSecurityContext to backup CronJob#1655

Open
snecklifter wants to merge 1 commit into
devfile:mainfrom
snecklifter:fix/backup-cronjob-podsecuritycontext
Open

fix(backup): apply configured podSecurityContext to backup CronJob#1655
snecklifter wants to merge 1 commit into
devfile:mainfrom
snecklifter:fix/backup-cronjob-podsecuritycontext

Conversation

@snecklifter

@snecklifter snecklifter commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Apply podSecurityContext from DevWorkspaceOperatorConfig to backup Job pod template
  • Consistent with how workspace deployments and PVC cleanup jobs apply the same config field
  • When podSecurityContext is not configured (nil), behavior is unchanged from current

Fixes #1636

Verification

Configure podSecurityContext in the DevWorkspaceOperatorConfig:

kubectl patch devworkspaceoperatorconfig devworkspace-operator-config \
  -n devworkspace-controller --type merge \
  -p '{"config":{"workspace":{"podSecurityContext":{"fsGroupChangePolicy":"OnRootMismatch"}}}}'

After a backup Job is created, confirm the security context is applied:

kubectl get job -l controller.devfile.io/devworkspace-backup=true \
  -o jsonpath='{.items[0].spec.template.spec.securityContext}'

Expected output should include the configured fsGroupChangePolicy.

Test plan

  • Unit test verifies backup Job uses configured podSecurityContext (custom FSGroupChangePolicy and SELinuxOptions)
  • Unit test verifies podSecurityContext is nil when not configured
  • All existing backup controller tests pass (go test ./controllers/backupcronjob/...)
  • go vet clean

Assisted-by: Claude Code

Summary by CodeRabbit

  • Bug Fixes
    • Backup jobs now inherit the configured pod security context, helping ensure they run with the expected security settings.
    • When no pod security context is configured, backup jobs continue to be created without one.

The backup CronJob controller does not set podSecurityContext on the
backup Job pod spec, even though DevWorkspaceOperatorConfig documents
that podSecurityContext applies to all workspace-related pods. This can
cause permission or SELinux failures when the backup container reads
workspace PVC data on clusters with a custom podSecurityContext.

Apply the configured podSecurityContext from DevWorkspaceOperatorConfig
to the backup Job pod template, consistent with workspace deployments
and PVC cleanup jobs.

Fixes: devfile#1636

Assisted-by: Claude Code

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Signed-off-by: Chris Brown <chribrow@redhat.com>
@openshift-ci

openshift-ci Bot commented Jun 19, 2026

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: snecklifter
Once this PR has been reviewed and has the lgtm label, please assign dkwon17 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@coderabbitai

coderabbitai Bot commented Jun 19, 2026

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

The backup CronJob’s generated Job pod template now applies WorkspaceConfig.PodSecurityContext from DevWorkspaceOperatorConfig. Tests cover both a configured custom context and the nil default case.

Changes

Backup CronJob security context

Layer / File(s) Summary
Pod security context wiring
controllers/backupcronjob/backupcronjob_controller.go, controllers/backupcronjob/backupcronjob_controller_test.go
createBackupJob sets the backup Job pod template SecurityContext from WorkspaceConfig.PodSecurityContext, and tests assert the configured and nil cases.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

  • devfile/devworkspace-operator#1638: Applies workspace.Config.Workspace.PodSecurityContext to another Job pod spec and verifies the resulting pod SecurityContext in tests.

Suggested reviewers

  • ibuziuk
  • akurinnoy
  • btjd
  • dkwon17

Poem

A bunny peeks at backup night,
and pats the pod context just right. 🐰
Soft carrots, safe pods,
with tests in neat clods,
now workspace backups hop light.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and concisely describes the main change: applying configured podSecurityContext to the backup CronJob.
Linked Issues check ✅ Passed The code and tests align with #1636 by applying the configured podSecurityContext to the backup Job pod template and covering the nil case.
Out of Scope Changes check ✅ Passed The changes are narrowly scoped to the backup Job pod security context and its unit tests, with no apparent unrelated additions.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@openshift-ci

openshift-ci Bot commented Jun 19, 2026

Copy link
Copy Markdown

Hi @snecklifter. Thanks for your PR.

I'm waiting for a devfile member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@tolusha

tolusha commented Jun 26, 2026

Copy link
Copy Markdown
Contributor

/che-ai-assistant ok-pr-readiness

Review is complete. Please check the review comments below.

@tolusha

tolusha commented Jun 26, 2026

Copy link
Copy Markdown
Contributor

PR Readiness Assessment: PR #1655 — fix(backup): apply configured podSecurityContext to backup CronJob

Repository: devfile/devworkspace-operator
Linked Issue: #1636 — Backup CronJob should apply DevWorkspaceOperatorConfig podSecurityContext


# Criterion Verdict Notes
1 Problem Statement PASS PR and linked issue clearly explain that backup Jobs don't inherit podSecurityContext from DevWorkspaceOperatorConfig, causing potential permission/SELinux failures on OpenShift clusters
2 Reproduction Steps WARN Issue describes the scenario (OpenShift with custom podSecurityContext) but lacks exact step-by-step instructions to reproduce the permission/SELinux failures in a real environment
3 Expected Behavior After Fix PASS Acceptance criteria clearly state backup Job should use configured podSecurityContext consistent with workspace Deployments; behavior when not configured is also defined
4 Scope of Changes PASS Minimal, focused change: 1 line added to production code, 2 comprehensive test cases added. Scope matches the problem description
5 Test Evidence PASS Two new unit tests verify: (1) custom podSecurityContext is applied, (2) nil when not configured. All existing tests pass, go vet clean
6 Deployment & Verification Notes WARN No guidance on how to verify the fix in a real environment: missing configuration example, observable behavior after deploying, or specific commands/logs to check

Overall: NEEDS WORK


Missing Information

  • Add reproduction steps: Describe the exact DevWorkspaceOperatorConfig YAML to trigger the issue (custom FSGroupChangePolicy, SELinux options, etc.) and the specific permission/SELinux error messages observed when a backup Job runs without the fix
  • Add verification guidance: Document how to configure podSecurityContext in DevWorkspaceOperatorConfig, what to observe when a backup Job pod is created (e.g., kubectl describe pod <backup-job-pod> showing SecurityContext), and any log entries or error messages that should no longer appear after the fix

What's Good

  • Clear problem statement: Both PR and issue provide excellent context on why backup Jobs need the same podSecurityContext as workspace Deployments
  • Strong test coverage: Two focused unit tests cover both the configured and unconfigured scenarios, with specific assertions on custom FSGroupChangePolicy and SELinuxOptions
  • Minimal, surgical fix: Single-line production code change makes it easy to review and reduces risk of regressions
  • Consistent with existing patterns: PR explicitly notes the change aligns with how workspace deployments and PVC cleanup jobs already apply this config field

Generated by Claude Code using ok-prerelease-verification:ok-pr-readiness

@snecklifter

Copy link
Copy Markdown
Contributor Author

@coderabbitai review

@coderabbitai

coderabbitai Bot commented Jun 26, 2026

Copy link
Copy Markdown
✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@coderabbitai coderabbitai 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.

🧹 Nitpick comments (1)
controllers/backupcronjob/backupcronjob_controller_test.go (1)

429-467: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Add By(...) steps to the new Ginkgo specs.

These tests add multiple setup/act/assert phases but don't document them with By(...), which is the repo convention for Ginkgo tests. As per coding guidelines, **/*_test.go: Use By("...") to document test steps in Ginkgo tests.

Also applies to: 469-501

🤖 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 `@controllers/backupcronjob/backupcronjob_controller_test.go` around lines 429
- 467, Add By(...) steps to the new Ginkgo spec in
backupcronjob_controller_test.go so the setup, execution, and assertions are
documented in the repo’s standard style. Update the affected It(...) blocks
around executeBackupSync and the job security context checks to use clear
By("...") markers for each phase, matching the existing Ginkgo conventions in
this test file.

Source: Coding guidelines

🤖 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.

Nitpick comments:
In `@controllers/backupcronjob/backupcronjob_controller_test.go`:
- Around line 429-467: Add By(...) steps to the new Ginkgo spec in
backupcronjob_controller_test.go so the setup, execution, and assertions are
documented in the repo’s standard style. Update the affected It(...) blocks
around executeBackupSync and the job security context checks to use clear
By("...") markers for each phase, matching the existing Ginkgo conventions in
this test file.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 1457482d-ebab-4591-92d1-594938b4bca9

📥 Commits

Reviewing files that changed from the base of the PR and between cdc8050 and 5280032.

📒 Files selected for processing (2)
  • controllers/backupcronjob/backupcronjob_controller.go
  • controllers/backupcronjob/backupcronjob_controller_test.go

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Backup CronJob should apply DevWorkspaceOperatorConfig podSecurityContext

2 participants