Add mobile push APNs settings (mobile_push.apns)

What does this MR do?

Exposes the mobile_push.apns application settings introduced in gitlab!248026 (merged) (APNs push notifications for GitLab mobile clients, dispatched on to-do creation — see also gitlab!248022 (merged) and gitlab!248023 (merged) for the subscription registry and REST API) to Omnibus installations:

  • New gitlab_rails['mobile_push_apns_auth_key_path'], ..._key_id, ..._team_id, and ..._topic attributes, rendered into gitlab.yml under mobile_push.apns (mirroring the microsoft_graph_mailer pattern).
  • Admins provide the path to an APNs provider token signing key (.p8) they place on disk themselves; key id and team id come from the Apple Developer account that owns the key.
  • Inert by default: with the attributes unset, the Rails side skips delivery entirely (Gitlab::MobilePush::ApnsClient#configured? is false).
  • Validated at reconfigure time (validate_mobile_push_settings! in libraries/gitlab_rails.rb): setting only some of the auth key path / key id / team id fails reconfigure naming the missing settings, and a configured key path that isn't a regular file prints a warning. Values are normalized first (coerced to stripped Strings, blank collapses to unset, and written back), so whitespace-only settings count as missing, non-String values fail reconfigure with an error naming each offending setting and its class, and a blank topic never reaches gitlab.yml, where it would override the Rails-side default (com.gitlab-mobile.app). The Rails runtime backstop for an unreadable key (rescue + error tracking instead of failing Sidekiq todo batches) is gitlab!250320 (merged).

Helm charts counterpart: gitlab-org/charts/gitlab!5257 (merged).

Testing

spec/chef/cookbooks/gitlab/recipes/gitlab-rails/gitlab_yml/mobile_push_spec.rb covers the default (unconfigured) rendering, user-specified values, the partial-configuration reconfigure failures (including empty-string, whitespace-only and single-missing variants), non-String rejection, the normalized rendering (padded values stripped, blank topic omitted so the Rails default applies), and the missing-key-file / directory-path warnings.

Related to gitlab#607602 and gitlab#607603 (feature rollout 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.
    • not adding: push delivery cannot be exercised by gitlab-qa (it requires Apple-issued device tokens and a reachable APNs), the registration API is covered by request specs in gitlab-org/gitlab, and this MR's surface is configuration rendering, covered by ChefSpec plus the package smoke above.
  • 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.
    • all four settings are plain strings rendered through the template's quote() helper (no integer/duration/URI formats involved); ChefSpec and the package smoke assert the rendered output, and validate_mobile_push_settings! rejects partial sets at reconfigure time. Ticking.
Edited by Marcel van Remmerden

Merge request reports

Loading
Loading