Skip frontend islands cleanup when the directory is absent

Rafa Fredericorequested to merge
tolerate-missing-frontend-islands into master

What does this MR do?

Guards the node_modules cleanup for ee/frontend_islands/apps in config/software/gitlab-rails.rb so it no longer fails when that directory is missing.

GitLab MR gitlab!259425 (merged) removes the ee/frontend_islands/ workspace. Its only app (Duo Next) was a removed prototype.

On EE builds, gitlab-rails.rb cleans up the islands node_modules with find .../ee/frontend_islands/apps -name 'node_modules' -type d -exec rm -rf {} +. When the directory is gone, find exits non-zero and the gitlab-rails build fails. This already breaks the EE package jobs in the package-and-test pipeline of that GitLab MR. For example, all Ubuntu package jobs failed with "find: ... No such file or directory" in https://gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/-/pipelines/2954494631.

This MR wraps the command in a test ! -d <dir> || find ... guard. The cleanup runs when the directory exists and is skipped when it does not. Packages now build both before and after the GitLab change.

The delete of ee/frontend_islands/node_modules above it is left as is. delete already tolerates a missing path.

No unit test applies here, because this is a build-step change and no spec covers software definitions.

Merge order

This MR should merge before the GitLab MR. Once the GitLab change has shipped in all supported versions built from this branch, both cleanup lines can be removed in a follow-up.

Test plan

  • Checked the shell guard locally.
  • With the directory present, find still matches node_modules and exits 0.
  • With the directory missing, the guarded command exits 0. The old command exits 1.
  • Trigger:ee-package and build-package-on-all-os passed with the directory present (GitLab master) and absent (GitLab at 48650d83). Links are in the review thread.

Related issues

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

  • MR title and description are up to date, accurate, and descriptive.
  • MR targeting the appropriate branch.
  • Latest Merge Result pipeline is green.
  • When ready for review, MR is labeled workflowready for review per the Distribution MR workflow.
  • The UBT version and corresponding checksum hash have been updated and referenced in the merge request if applicable.
    • UBT EE pipeline (Trigger:ee-package-ubt) is green

For GitLab team members

If you don't have access to this, the reviewer should trigger these jobs for you during the review process.

  • The manual Trigger:ee-package jobs have a green pipeline running against latest commit.
  • If config/software or config/patches directories are changed, make sure the build-package-on-all-os job within the Trigger:ee-package downstream pipeline succeeded.
  • If you are changing anything SSL related, then the Trigger:package:fips manual job within the Trigger:ee-package downstream pipeline must succeed.
  • If CI configuration is changed, the branch must be pushed to dev.gitlab.org to confirm regular branch builds aren't broken.

Expected (please provide an explanation if not completing)

  • Test plan indicating conditions for success has been posted and passes.
  • Documentation created/updated.
  • Tests added.
  • Integration tests added to GitLab QA.
  • Equivalent MR/issue for the GitLab Chart opened.
  • Validate potential values for new configuration settings. Formats such as integer 10, duration 10s, URI scheme://user:passwd@host:port may require quotation or other special handling when rendered in a template and written to a configuration file.

🤖 Generated with Claude Code

Edited by Rafa Frederico

Merge request reports