You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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]>
0 commit comments