Expose each role's stable machine key on Gitlab::Glaz.roles

Bojan Marjanovicrequested to merge
bm/expose-role-key into main

What does this MR do and why?

Every entry of Gitlab::Glaz.roles now carries :key, the role's stable machine identifier (e.g. "artifact_admin"), alongside the existing :id, :name, and :permissions.

The glaz-roles crate has carried Role::key since before the pinned revision (0c90ffcd), and GLAZ exposes it on the ListRoles wire type via glaz!175. But the gem's roles path never goes through the proto — the Magnus binding calls glaz_roles::default_roles() directly and hand-builds the Ruby hash, and it simply never copied key across. The field was sitting in scope, unused.

That left callers hardcoding a role's UUID or matching on :name, which is human-facing and may be reworded. The gem's own specs did the latter.

Two things kept this invisible:

  • spec/gitlab/glaz/roles_spec.rb asserted the hash keys with contain_exactly(:id, :name, :permissions) — an exact match, so it would have failed the moment anyone added :key. The omission was locked in by a green test.
  • The doc comments on both the native roles() and Gitlab::Glaz.roles restated the three-field shape.

Changes

  • ext/glaz/src/lib.rs: roles() sets :key from Role::key; doc comment updated to explain what the key is for.
  • lib/gitlab/glaz.rb: doc comment updated; the wrapper only freezes what the native function returns, so no other change was needed. Hashes stay deep-frozen.
  • spec/gitlab/glaz/roles_spec.rb: expects :key, asserts its format and that keys are distinct, and looks the Artifact Registry roles up by key rather than by display name.
  • CHANGELOG.md: entry under [Unreleased].

Additive only — nothing is removed or renamed, so this is a minor bump when released. Following this repo's convention, the version bump is left to a separate release MR.

Follow-up, not in this MR

A caller can now read a role's key but still has to send its UUID: the inbound relationships.v1.Role message is still id-only. Worth a separate issue upstream.

How to set up and validate locally

  1. bundle install
  2. bundle exec rake compile
  3. bundle exec rspec spec/gitlab/glaz/roles_spec.rb
  4. Confirm the key is actually exposed: 
    bundle exec ruby -Ilib -e 'require "gitlab/glaz"; pp Gitlab::Glaz.roles.map { |r| r.slice(:key, :name) }'
    [{key: "artifact_admin", name: "Artifact Admin"},
 {key: "artifact_contributor", name: "Artifact Contributor"},
 {key: "artifact_manager", name: "Artifact Manager"},
 {key: "artifact_viewer", name: "Artifact Viewer"},
 {key: "organization_admin", name: "Organization Administrator"}]

Verified locally

  • bundle exec rspec — 135 examples, 0 failures
  • bundle exec rubocop — 20 files, no offenses
  • cargo fmt --all --check — clean
  • bundle exec rake compile — clean

Ran against Ruby 4.0.6 rather than the pinned 4.0.7, which was not installed locally; CI covers the pinned version. Bare cargo clippy cannot build magnus without the rb-sys environment that rake compile sets up — that failure reproduces on an unmodified checkout and is unrelated to this change.

🤖 Generated with Claude Code

Merge request reports