Skip to content

Conversation

dscho
Copy link
Member

@dscho dscho commented Oct 6, 2025

This is the culmination of the huge journey that started with the big chunk of work ending in #4 (evacuating GitGitGadget from Azure Pipelines and running everything in GitHub workflows instead).

There are still a couple of PRs that need to be merged before this here PR can be merged:

When forking GitGitGadget's GitHub App, GitHub Actions are turned off by
default. Allow deploying the App in such circumstances by adding a
workflow dispatch trigger.

Signed-off-by: Johannes Schindelin <[email protected]>
This allows overriding the default Azure Function name used for
deploying via setting a repository secret (in Settings>Secrets and
variables).

The name of the Azure Function is treated as a secret because it can be
used to derive the URL of the Azure Function and to attempt to DOS it.

At this point, it is not _actually_ necessary to provide the correct
Azure Function app name here, as we are using a so-called "publish
profile" that overrides the app name.

However, we are about to switch to Role-Based Access Control, where it
very much matters whether the correct name is specified or not.

Signed-off-by: Johannes Schindelin <[email protected]>
Apparently the `publish-profile` deployments are no longer working as
expected for recently-created Azure Functions. That is, the existing
`gitgitgadget` Function still works, obviously, but when I registered a
new Function as described in the `README.md` and tried to deploy it the
same way as `gitgitgadget`, it failed thusly:

  ▶ Run Azure/functions-action@v1
  Successfully parsed SCM credential from publish-profile format.
  Using SCM credential for authentication, GitHub Action will not perform resource validation.
  (node:1549) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
  (Use `node --trace-deprecation ...` to show where the warning was created)
  Error: Execution Exception (state: ValidateAzureResource) (step: Invocation)
  Error:   When request Azure resource at ValidateAzureResource, Get Function App Settings : Failed to acquire app settings from https://<scmsite>/api/settings with publish-profile
  Error:     Failed to fetch Kudu App Settings.
  Unauthorized (CODE: 401)
  Error:       Error: Failed to fetch Kudu App Settings.
  Unauthorized (CODE: 401)
      at Kudu.<anonymous> (/home/runner/work/_actions/Azure/functions-action/v1/lib/appservice-rest/Kudu/azure-app-kudu-service.js:69:23)
      at Generator.next (<anonymous>)
      at fulfilled (/home/runner/work/_actions/Azure/functions-action/v1/lib/appservice-rest/Kudu/azure-app-kudu-service.js:5:58)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)
  Error: Deployment Failed!

My guess is that finally the reality of publish profiles being highly
insecure has caught up with new Azure Function registrations, and it is
now required to use much more secure methods instead.

Let's use OpenID Connect, as it is tied to the GitHub workflow and is
therefore as secure as it gets. Even if the name of the Managed
Identity, the tenant and the subscription IDs are known, an attacker
cannot authenticate as that managed identity.

Signed-off-by: Johannes Schindelin <[email protected]>
With this change, the GitGitGadget GitHub App truly learns about
projects other than Git.

Instead of hard-coding the respective project-dependent values, it now
reads the project configuration from the `gitgitgadget-config.json`
file, which adheres to the `IConfig` interface defined in
https://github.com/gitgitgadget/gitgitgadget/blob/HEAD/lib/project-config.ts.

One caveat: Since the App needs to know which `gitgitgadget-workflows`
fork to target when triggering the GitHub workflows, an additional entry
is required in the configuration that is _not_ defined in `IConfig`:

	workflowsRepo: {
		owner: "gitgitgadget-workflows",
		name: "gitgitgadget-workflows"
	}

Signed-off-by: Johannes Schindelin <[email protected]>
It would be nice if we could deploy the Azure Function contingent on the
presence of the `AZURE_CLIENT_ID` secret. However, this is not possible
in GitHub workflows: the job-level `if:` conditions lack access to the
`secrets` context. Strangely enough, they _do_ have access to the `vars`
context...

To successfully deploy the Azure Function, it needs to know which
`gitgitgadget-workflows` fork to target when triggering workflow runs,
anyway, so let's _require_ a repository variable called
`DEPLOY_WITH_WORKFLOWS` that specifies that fork in the form
`<org>/gitgitgadget-workflows`.

Note that such a `gitgitgadget-workflows` fork _must_ have the `config`
branch, with a `gitgitgadget-config.json` file that contains the
corresponding project configuration; The `deploy` workflow will retrieve
this configuration and overwrite `gitgitgadget-config.json` with it,
augmenting the `workflowsRepo` information on the fly.

Signed-off-by: Johannes Schindelin <[email protected]>
Now that I am trying to establish support for projects other than Git, I
need to register a new GitHub App. Let's document that process better
for the next person who wants to repeat that feat.

Signed-off-by: Johannes Schindelin <[email protected]>
@dscho dscho self-assigned this Oct 6, 2025
@dscho
Copy link
Member Author

dscho commented Oct 7, 2025

Ooops. I had forgotten that I had already a PR for this: #7. I updated its branch and description and will close this here PR in favor of that one.

@dscho dscho closed this Oct 7, 2025
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.

1 participant