Bad credentials

[cheesytim]

Hi there!
The preview deploy has done and works, but I got a error with credentials, I thought fails-without-credentials: false flag will help me, but..

config:

on:
  pull_request:
    branches: 
      - main
    tags-ignore:
      - 'v*.*'

jobs:
  build:
    runs-on: ubuntu-18.04
    steps:
      ...build script

      - name: Deploy to Netlify
        uses: nwtgck/actions-netlify@v1.2.2
        if: startsWith(github.head_ref, 'dependabot/*') == false
        with:
          publish-dir: 'storybook-static'
          production-branch: main
          github-token: Qvant-lab:${{ secrets.GITHUB_TOKEN }}
          enable-commit-comment: true
          overwrites-pull-request-comment: true
          fails-without-credentials: false
        env:
          NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
          NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}
        timeout-minutes: 1

on: push works fine, trouble with pull_request
Repo:
https://github.com/Qvant-lab/qui-max

[polarathene]

trouble with pull_request

The secrets context is not available in pull_request event triggered workflows. This is because anyone can modify that workflow via their PR which when run (first-time contributors require your approval, but not after you merge their first PR), a malicious user could modify the workflow to access secrets, which would not be good for you.

Instead you can use workflow_run as a separate workflow to have access to secrets, but you'll want to use the pull_request workflow separately to build the PR in an untrusted context without access to secrets if anything in the PR could control / manipulate what is executed in the workflow (such as the build process).

That complicates it a bit, especially if you need context metadata about your PR. You could use pull_request_target to handle it in a single workflow, but you will need to ensure that anything untrusted from the PR is prevented from compromising your secrets. You'd need to lock down permissions, as those affect the GITHUB_TOKEN which REST APIs of actions will use (or an attacker with access to the token), and you'll need to use actions/checkout with the correct repo and ref of the PR to clone, whilst setting persist-credentials: false for that action since the GITHUB_TOKEN would otherwise be stored at .git/config which the PR could likewise steal/use.

It's possible for workflow_run approach to use it's own event context for the metadata you need, except that doesn't work with PRs from forks, hence the pull_request_target approach is a bit more convenient, provided you take the extra precautions.

Do note that this action doesn't play well with either workflow_run (or partially with pull_request_target too) with a variety of it's features that internally use event context but don't allow you to configure it for the action. enable-commit-comment for example can add the deployment comment on a master/main branch commit if you update a PR branch (merges base branch back into the PR), when restricting permissions you'll also need to ensure you have these granted for such features (but the action does not document them nor handle errors related to it when that's missing).

fails-without-credentials: true is opt-in feature to fail the action when the credentials have not been passed to the actions env. That's all it does, stops the action from continuing and outputs an error.

github-token has a check for the value to not be empty, if it is it'll silently return, preventing other features from working. But in your case the credentials for Netlify are missing due to the pull_request trigger, and that's a good thing.