Deploy a Fabric app with GitHub Actions

Hi dinunoroc​,

The error is specific: the deploy authenticates fine and can write the app item, but the runtime settings sync step checks that the deploying identity, your service principal, has Build on the semantic model referenced by the fabric-semanticmodel connector. The GitHub Actions guide only lists Contributor on the target workspace, which covers the app item, not the connected model.

The most common reason Contributor/Member still isn't enough:

rayfin.yml connector
  workspaceId: <model workspace>   <- often NOT the deploy workspace
  itemId:      895b5565-...

SP is Contributor on the deploy workspace
-> but has no role / no Build on the model's workspace
-> 403 "Could not verify Build permission"

Check the workspaceId in the connector config first. If the model lives in a different workspace, give the SP access there. Either option works:

option A: add the SP to the model's workspace as Contributor
          (workspace roles Contributor+ include Build on its models)
option B: share only the model with the SP, with Build
          (Manage permissions on the semantic model)

Option B is the least-privilege route, and it can be scripted with the Power BI REST API. "ReadExplore" is Read + Build:

Connect-PowerBIServiceAccount   # as a model owner / workspace admin

$ws    = "<model-workspace-id>"
$model = "895b5565-1234-4cff-a0e0-5d322exxxxxx"

$body = @{
    identifier             = "<service-principal-object-id>"   # enterprise app object ID
    principalType          = "App"
    datasetUserAccessRight = "ReadExplore"
} | ConvertTo-Json

Invoke-PowerBIRestMethod -Method Post `
    -Url "groups/$ws/datasets/$model/users" -Body $body

Note the identifier is the Enterprise application object ID, not the app registration's client ID. Mixing those up is a common cause of "permission granted but still 403".

Two other things worth confirming with your Fabric admin, since both affect only service principals:

tenant setting: service principals can use Fabric / Power BI APIs
  -> if scoped to a security group, the SP must be in it
the model's workspace must allow API access for that SP
  (same tenant setting applies there too)

After granting Build, re-run the workflow as is; the error message's "re-add the connector" shouldn't be needed once the permission check passes. Also keep in mind that the semantic model connector uses delegated auth at runtime, so app users still need their own access to the model. The SP's Build only matters for deployment.

Your other thread's notes on the sample workflow (missing line continuations, the $ on CLIENT_SECRET, libsecret on ubuntu-latest) are spot on as well. Worth submitting as feedback on the docs page.

So my overall approach would be:

check connector workspaceId vs deploy workspace
-> grant the SP Build on that model (or Contributor on its workspace)
-> use the Enterprise app object ID when sharing via API
-> confirm the SP tenant setting covers it
-> re-run rayfin up

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.