Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Hubs] Pass hub options to newHub() as an object instead of positional arguments

Open Beginner friendly
  • Is something wrong?
#2,354 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 6 days

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Refactor
Clarity
Clearly specified
Activity status
Active
Tech stack
azure
Domain
infrastructure

Research direction

Start with src/templates/finops-hub/modules/fx/hub-types.bicep, then inspect the sole caller in modules/hub.bicep. Confirm whether #2249 has merged before including its Key Vault RBAC option, and update both function signatures and the caller to pass named options. Validate the Bicep templates and verify that the deployed resources remain unchanged.

Written by the indexing model from the issue text.

Description

Tool: FinOps hubs Type: Cleanup

📝 Scenario

newHub() and newHubInternal() in src/templates/finops-hub/modules/fx/hub-types.bicep take all hub options as positional arguments. newHub() has 12 parameters today and newHubInternal() has 15, many of them adjacent values of the same type (storageSku/keyVaultSku, and a run of bool flags such as keyVaultEnablePurgeProtection, enableInfrastructureEncryption, enablePublicAccess, enableNatGateway).

Every new hub option adds another positional argument, often inserted in the middle of the signature. #2249 does that with keyVaultEnableRbacAuthorization. If two arguments of the same type end up in the wrong order at a call site, the template still compiles, and the hub is silently configured wrong (for example, purge protection and infrastructure encryption swapped).

There's only one caller today (modules/hub.bicep), so the risk is contained for now, but it grows with each option.

This came up during the review of #2249 and was agreed to be out of scope there.

💎 Solution

Change newHub() and newHubInternal() to take the options as a single typed object parameter, for example a HubOptions user-defined type, so call sites name each option:

var hub = newHub(hubName, location, {
  tags: tags
  tagsByResource: tagsByResource
  storageSku: storageSku
  keyVaultSku: keyVaultSku
  keyVaultEnablePurgeProtection: enablePurgeProtection
  enableInfrastructureEncryption: enableInfrastructureEncryption
  enablePublicAccess: enablePublicAccess
  enableNatGateway: enableNatGateway
  networkAddressPrefix: virtualNetworkAddressPrefix
  isTelemetryEnabled: enableDefaultTelemetry
})

If a full refactor isn't wanted, the minimum is a convention that new options are appended at the end of the signature instead of being inserted in the middle.

This is an internal refactoring with no change to deployed resources. It's best done after #2249 merges, so it includes the Key Vault RBAC option.

Dominant language
PowerShell
Stars
614
Forks
260
Avg merge
4d 3h
Merged PRs (30d)
5

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/finops-toolkit

All issues in microsoft/finops-toolkit

Similar issues

More DevOps issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.