Add vue3_migrate_admin_applications flag and migrate admin applications pages
What does this MR do and why?
Adds the vue3_migrate_admin_applications feature flag and opts the admin applications page entrypoint into the Vue 3 migration.
With status: rollout, the bundler builds both a Vue 2 and a Vue 3 chunk for the entrypoint. Gitlab::Vue3Migration.entrypoint_for then picks between them per request, using current_user as the actor. That gives us a gradual ramp and instant rollback.
The flag ships disabled, so merging this changes nothing for users. The same components render, just on a different Vue runtime.
Entrypoints in this MR
| Entrypoint | Vue apps mounted |
|---|---|
admin/applications |
WebIdeOAuthApplicationCallout (edit page), DeleteApplicationRoot (list/show pages), OAuthSecretRoot (show page) |
pages/admin/applications/ has no action-specific subdirectories, so this single entry serves all actions of Admin::ApplicationsController — index, new, show, and edit — and the yml covers them all. On new, all three init functions no-op (no mount selectors present), so the page runs the Vue 3 runtime with zero apps mounted.
The entrypoint is not shadowed under ee/app/assets/javascripts/pages, so no EE counterpart is required by spec/lib/gitlab/vue3_migration_files_spec.rb. No Vuex, vue-router, VueApollo, or portal-vue on this page.
Ownership note: Admin::ApplicationsController is feature_category :system_access. Source Code owns the Web IDE OAuth callout, but the delete-application and OAuth-secret apps belong to the system access domain. Since vue3_migration.yml applies to the whole page entrypoint, all three apps migrate together — a courtesy check with the owning group is planned before ramping past gitlab-org (tracked on the issue).
Testing
Run with the flag enabled (Feature.enable(:vue3_migrate_admin_applications)), after gdk restart rails-web and gdk restart vite. Vite builds its page entry map at startup, so it will not serve a new entrypoint without a restart.
Verify a page is on Vue 3 with document.querySelectorAll('[data-gitlab-vue3-app]'). initVueApp also logs [V] Using Vue.js 3 ... once per named app.
/admin/applications (index):
- Page loads with no console errors
- Delete-application modal opens from a row's delete button and deleting works end to end
/admin/applications/new:
- Page loads with no console errors (no Vue apps are expected to mount here)
- Submitting the form creates the application and lands on the show page
Application show page:
- OAuth secret copy button and visibility toggle both work
- Renew secret confirmation modal opens and renews the secret
- Delete-application modal opens and deleting works
Application edit page:
- Web IDE OAuth callout renders
- Reset application settings modal (Restore to default) opens and confirms
On each state above:
- Console check — Vue 3 roots present, zero Vue 2 roots remain:
// Vue 3 apps
[...document.querySelectorAll('[data-gitlab-vue3-app]')].map((el) => el.dataset.gitlabVue3App);
// Vue 2 apps - should be empty once the flag is on
[...document.querySelectorAll('*')].filter((el) => el.__vue__ && el.__vue__.$root === el.__vue__)
.map((el) => el.__vue__.$options.name);Scope check:
- With the flag disabled, all pages render the Vue 2 bundle unchanged (
[data-gitlab-vue3-app]is empty) -
bundle exec rspec spec/lib/gitlab/vue3_migration_files_spec.rbpasses
Notes for reviewers
No changelog entry: there is no user-facing change, and the flag ships disabled.
No new tests: spec/lib/gitlab/vue3_migration_files_spec.rb already validates the yml schema, that the referenced flag exists, and CE/EE consistency. Component behaviour is covered by the existing Jest suites (oauth_application_callout_spec.js, reset_application_settings_modal_spec.js, delete_application_spec.js, oauth_secret_spec.js), which run under VUE_VERSION=3.
Worth noting: spec/features/admin/admin_manage_applications_spec.rb is not a :js spec, so nothing exercises these Vue apps end to end in CI. The manual smoke test above covers that gap before ramping.
The OAuth secret app (~/oauth_application/index.js) still mounts via legacy new Vue() rather than initVueApp; it runs through the compat layer either way, but it is the first place to look if smoke testing finds an issue.
Rollout
Enable for gitlab-org and dogfood for about a week, then 25% and 100% (compressed ramp, per the issue). Then default_enabled: true, then a cleanup MR flipping the yml to status: migrated and removing the flag.
References
- Issue: #618745 (closed)
- Epic: gitlab-org#23084
- Migration docs: https://docs.gitlab.com/development/fe_guide/vue3_migration/
- Same pattern as: !251075 (merged)