Consume project-specific settings from the CONFIG repository variable #7
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 fork _must_ have the `CONFIG` repository variable 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. Also note: In order to read that `CONFIG` repository variable (which for some unfathomable reason cannot be read via the regular `GITHUB_TOKEN` available in GitHub workflows...), the GitHub App needs to be installed on that repository and configured in this here repository via the `GITGITGADGET_GITHUB_APP_ID` and `GITGITGADGET_GITHUB_APP_PRIVATE_KEY` secrets. This poses a bit of a Catch-22 because the Azure Function is expected to already be deployed when the GitHub App is registered, but the workflow should be used for the initial deployment, too. To accommodate for that, instead of erroring out, the workflow will merely warn when the repository variable cannot be read, and continue with the default configuration instead. Those secrets should be defined directly after registering the GitHub App. Signed-off-by: Johannes Schindelin <[email protected]>
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]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, GitGitGadget supports only PRs for the Git project. However, there was already a ton of work to encapsulate project-specific information via the IConfig interface.
In gitgitgadget/gitgitgadget-workflows#13, we already moved this configuration into the
CONFIGrepository variable of thegitgitgadget-workflowsrepository.Since the GitHub App needs to know in which of the
gitgitgadget-workflowsforks it is supposed to trigger the GitHub workflows, it can just as well retrieve the project configuration from there, too. To this end, theDEPLOY_WITH_WORKFLOWSrepository variable on thegitgitgadget-github-appfork needs to point there; I took the liberty to already do that in this here repository, it is set togitgitgadget-workflows/gitgitgadget-workflows.To allow the tests to run in PR builds, the original project configuration is committed into the repository.
This default configuration also comes in handy when standing up a new instance of GitGitGadget's GitHub App: Due to the Catch-22 that the GitHub App can only be registered when there is already a deployed Azure Function, but to deploy that, the
deploy-to-azureworkflow needs the GitHub App's credentials to be allowed to access the repository variable, the first deployment will simply have to use the default configuration, and once the GitHub App is registered and its credentials are made available to thedeploy-to-azureworkflow, the Azure Function will need to be deployed again (this time with the intended project configuration).This PR is stacked on #5 and on #6, and needs gitgitgadget/gitgitgadget-workflows#13 to be merged first.