Default behavior for PR builds from forks fails

[clairernovotny]

A very common scenario is people outside the repo contributing PR's. The current default Actions template fails the PR since the secrets aren't available.

At the very least, it should still build but then pass the PR without doing any deploy.

This should be fixed soon or people who try it out may quickly get frustrated and remove it since all their PR's fail.

[dariagrigoriu]

We are planning to consider build and pass the PR without deployment as future behavior. Pre-production environments are limited and auto-deployment in this scenario may not be what the app owner intends in all cases.

[clairernovotny]

What if we do want to auto deploy those?

[orta]

Hi folks, pretty advanced GitHub Actions user here. Now that we can have microsoft repos use SWA, I got it running for TypeScript. I have it set up to deploy for on an open source repo for external PRs, but I need to find a way to get the URL back into my PR.

Here's what I originally did:

1. I set up the repo in azure portal
2. I refactored that new workflow into my normal CI workflow

This hit the 'public repos' don't get secrets issue. Which is fine, because workflow_run exists.

Here's how it works:

Now, my CI builds an artifact of the static site on CI instead of deploying. That artifact is passed to a workflow_run action which then uploads it (because it has access to the secrets)

• CI.yml
• CI-post.yml

This allows an OSS repo to get contribution PRs which trigger the upload. Doing it this way doesn't get the message back in the comment thread however, but it does upload

So my request is that the GitHub Action sets an output of the URL, then I can have all sorts of ways of grabbing the URL and presenting it to users. ( I built danger-js for this use-case a few years ago. )

If someone reaches out to me on MS teams, to let me know where code lives - I can help ship that code get that to work. Otherwise I'll look around and see if there are APIs I can use to find the URL like https://nice-meadow-0c9756810.azurestaticapps.net

[clairernovotny]

@orta that's awesome!

[miwebst]

@orta this is super cool! Having the url as an output is something a lot of folks have asked for especially for performing tests after deployment. The challenge for us is that we run inside a Docker based Github Action. Do you know of anyway to set the output for the action when using Docker based actions?

[orta]

I do, the way it works is that GH listens to specially crafted stdout messages from your action to determine outputs.

I'll assume bash (for my familiarity), but realistically it can be anything:

echo “::set-output name=<output name>::<value>”

e.g.

echo “::set-output name=static_web_app_deploy_url::https://nice-meadow-0c9756810.azurestaticapps.net”

Would let me pick that up in another workflow step, there's some docs here with sample code here

[miwebst]

Small update, we did get a working prototype of this! Thanks for the help. I will followup once we've finished testing and released it.

[miwebst]

This is now in production, you can access the build and deploy output like so:

${{ steps.builddeploy.outputs.static_web_app_url }}

[orta]

Thanks!

[orta]

👋🏻 - I've been working on a sample repo which shows the OSS PR process. Here's how it works so far, and then after, why it's not working yet.

Repo: https://github.com/orta/pr-builds-static-web-apps
Workflow Files: One for CI then a Post-CI yml

( I'd open ^ in a new window to run along-side this comment, they're well commented )

The Problem

A cross-fork PR does not get the access token to push to azure. The token is a secret, and secrets aren't shared to fork PRs, which is a reasonable security measure by GitHub on GH Actions.

Other static site providers like next/gatsby/etc will build the PR builds themselves, and don't have this problem. Because SWA build happens on GH Actions, then the security model of GH Actions affects PR builds.

The Solution

Use the new workflow_run process in GitHub Actions. Basically the CI run has limited access, but you can pass an artifact from that build to a workflow which happens after CI.

So, we pass the built version of the site and some PR metadata to a workflow_run which uploads to SWA. Then I use danger to send a message to the PR.

The Process

• The CI generates all the *.html files
• The CI adds the PR JSON to the same folder as the html files
• The CI uploads the html files as an archived zip
• After the CI is finished, the Post-CI workflow starts
• The Post-CI workflow downloads the zip
• The Post-CI workflow uploads the SWA
• The Post-CI workflow triggers a danger run passing the URL from the SWA in

You can see a working PR here: orta/pr-builds-static-web-apps#5

What Doesn't Work

It only uploads to the 'master' environment, I've tried using a custom branch and pushing that but I think the dockerfile makes assumptions that it is being ran in a PR workflow and I'd need some args which let me define the environment

I wondered if it was tied to the current branch, so I explored running that action when the other PR was checked out but that didn't work.

Potential Solutions

1. Allow some kind of anonymous upload feature to SWA, then you don't have to do all of the above faff. If someone wants to chat about what that could look like, feel free to ping me on MS Teams.

2. Add some more args to uses: Azure/static-web-apps-deploy. I could imagine environment as a string.

    # Uploads the static build
    - name: Build And Deploy
      uses: Azure/[email protected]
      id: deploy
      with:
        azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_ICY_MOSS_0DAC87810 }}
        repo_token: ${{ secrets.GITHUB_TOKEN }}
        action: "upload"
        app_location: "built"
        app_artifact_location: "public"

        environment: "pr_${{ steps.pr_info.outputs.number }}"

or the PR meta could be manually added instead:

      # Uploads the static build
      - name: Build And Deploy
        uses: Azure/[email protected]
        id: deploy
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_ICY_MOSS_0DAC87810 }}
          repo_token: ${{ secrets.GITHUB_TOKEN }}
          action: "upload"
          app_location: "built"
          app_artifact_location: "public"

          repo: ${{ steps.pr_info.outputs.number }}
          pull_number: ${{ steps.pr_info.outputs.number }}

This would let this technique work, but dang the whole thing a bit unfriendly and requires quite a lot of knowledge about how GH Actions works for something which I think someone would expect to kinda work out of the box.

3. Support building on Azure, which is kinda a roundabout way of re-running GH actions I guess. I'm not a general fan of the idea, but I don't have to build it, though that is what the competition is doing,

[cmaneu]

Hello there,
I have the same issue for this opensource project ( See here).

@orta proposed solution (capturing the artifact and using workflow_run) is interesting. My only remark would be time to capture the artifacts (can be time-consuming, specially with some languages).

Some alternative ideas:

• Use the pull_request_target that uses the workflow file of the target branch and not the one from the merge commit.
• Have a way to deploy from PR comments, like "#swa-deploy" (could leverage issue_comment and if: ${{ github.event.issue.pull_request }} ).

I haven't tested them yet, but I can dedicate some time trying something if asked :).

[andrewbranch]

It seems like the workaround that @orta proposed is now possible via deployment_environment and production_branch inputs. I have something working between the CI.yml, deploy-preview.yml, and close-preview.yml workflows at https://github.com/microsoft/TypeScript-Website/tree/v2/.github/workflows. Branch-based PRs use the simple approach. Fork-based PRs upload the built site as an artifact, which is then downloaded and deployed when (1) a magic label is added to the PR, (2) the CI workflow completes on such a labeled PR, or (3) a workflow_dispatch is run. The script to find the artifact differs slightly between each of these scenarios. It took me over a day of work to sort it all out. So yeah, it’s possible, but not exactly a cakewalk.