Skip to content

feat(runner_account): support a differently named primary group#29

Merged
jcardozo-eth merged 2 commits into
mainfrom
feat/runner-account-custom-group
Jul 23, 2026
Merged

feat(runner_account): support a differently named primary group#29
jcardozo-eth merged 2 commits into
mainfrom
feat/runner-account-custom-group

Conversation

@jcardozo-eth

@jcardozo-eth jcardozo-eth commented Jul 23, 2026

Copy link
Copy Markdown
Member

Closes #25.

Changes

The runner_account struct gains an optional group key naming the account's primary group. It defaults to the account name, so existing hosts render and apply identically; set it when an externally provisioned account's primary group is named differently from the account (e.g. account ci-worker, primary group ci).

On Linux, a file (and a user account) has both an owner and a group. The module used the account name for both, so it worked only when the account's primary group shared the account's name. An externally created account whose group is named differently then failed on its first apply: the module tried to use the account name as the group, and no such group exists.

group separates the two. The account name still owns everything the module creates; the group value is used wherever the module sets a group: the group and primary group it gives the account when it manages the account, and the group of the runner configuration file, its directory, the .runner_system_id file, and the account's ~/.config/systemd/user folder.

The default is an absent key with the fallback resolved once in code, because the module data layer cannot express "same as the account name". Unset, the account name doubles as the group, which is correct by construction where the module creates the account.

Verification

  • New tests thread a non-default group into every derived resource (extending the ownership-derivation context for the externally-owned case, plus the managed-account case for the group resource and the user's gid), and assert the default falls back to the account name. Both directions are mutation-checked: breaking the derivation fails exactly the custom-group cases while the fallback cases stay green.
  • An unknown sibling key still fails the compile, and the key participates in the deep-merge lookup like the rest of the struct.
  • Full gate green: 116 rspec examples, puppet-lint, metadata-json-lint, yamllint, and the REFERENCE.md docs check.

The runner_account struct gains an optional `group` key naming the
account's primary group. It defaults to the account name, so existing
hosts render and apply identically; set it for an externally provisioned
account whose primary group is named differently (account ci-worker,
group ci), where the account name is not itself a resolvable group and
the first apply would otherwise fail to find it.

The group is derived once (falling back to the name) and threaded into
every group ownership the module manages: the managed group and the
user's gid where the account is owned here, and the group of the runner
configuration file, its directory, the .runner_system_id file, and the
account's systemd user tree. Owners stay the account name throughout.

The module data layer cannot express "same as name", so the default is
an absent key with the fallback resolved in code.
The `ci-worker`/`ci` pair in the runner_account.group option doc and the
README is an example, not a default or a shipped name. Prefix it with
"e.g." so it does not read as a fixed value.
@jcardozo-eth jcardozo-eth self-assigned this Jul 23, 2026
@jcardozo-eth
jcardozo-eth merged commit 446c267 into main Jul 23, 2026
3 checks passed
@jcardozo-eth
jcardozo-eth deleted the feat/runner-account-custom-group branch July 23, 2026 08:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support a runner account with a differently named primary group

1 participant