To get the example to work (i.e. to have one workflow wait for another to complete) you need two files. Both files live in the .github/workflows folder of a repository.

The first file would be set up as usual. This file will be triggered by whatever event(s) are set in the on section:

---
name: Preflight

on:
  - pull_request
  - push

jobs:
  preflight-job:
    name: Preflight Step
    runs-on: ubuntu-latest
    steps:
      - run: env

The second file states that it should only trigger on the workflow_run event for any workflows with the name Preflight and must be on your repository's default branch, usually main or master:

---
name: Test

on:
  workflow_run:
    workflows:
      - Preflight
    types:
      - completed

jobs:
  test-job:
    name: Test Step
    runs-on: ubuntu-latest
    steps:
      - run: env

This more-or-less the same as the example from the GitHub Actions manual.

As you can see on the actions page of my example repo, the Preflight workflow will run first. After it has completed, the Test workflow will be triggered:

When you try this out, you will find that the Test workflow always runs the code and workflow configuration on your default branch, usually main or master.

This is because, (quoting from the manual):

This event will only trigger a workflow run if the workflow file is on the default branch.

This means you'll need to develop workflows triggered by workflow_run on your default branch, which is a little unfortunate.

This also means that if you need the "Test" workflow to run against the code of your branch or pull request, then you'll need to do more work as described below:

Every actions is run with a set of contexts. The github context holds information about the event that triggered the workflow. This includes the branch that the event was originally triggered from/for: github.event.workflow_run.head_branch.

This can be used to check out the origination branch in the action, using the actions/checkout action provided by GitHub.

To do this, the Yaml would be:

---
name: Test

on:
  workflow_run:
    workflows:
      - Preflight
    types:
      - completed

jobs:
  test-job:
    name: Test Step
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          repository: '${{ github.event.workflow_run.head_repository.full_name }}'
          ref: ${{ github.event.workflow_run.head_branch }}
      - run: git branch
      - run: env

https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run

The workflow_run event only works on the default branch.

instead of using workflow_run, look at using reusable workflows. Then in your code quality workflow, if everything works there, you would call a reusable workflow to do the testing.

Since Sept. 2022, there might be a way to set the title of the run itself:

GitHub Actions: Dynamic names for workflow runs (Sep. 2022)

GitHub Actions customers can now dynamically name their workflow runs.
The new run-name feature will accept expressions and be displayed on the list of workflow runs.

For more information on how to use run-name, visit the documentation.

For questions, visit the GitHub Actions community.

To see what's next for Actions, visit our public roadmap.

You now have:

The name for workflow runs generated from the workflow.
GitHub displays the workflow run name in the list of workflow runs on your repository's "Actions" tab.
If you omit run-name, the run name is set to event-specific information for the workflow run.
For example, for a workflow triggered by a push or pull_request event, it is set as the commit message.

This value can include expressions and can reference the github and inputs contexts.

Example

run-name: Deploy to ${{ inputs.deploy_target }} by @${{ github.actor }}

To expand on the documentation:

Example

Consider, as an example, a workflow in a project that involves both feature development and bug fixes.
That project uses two primary types of branches:

• Feature branches: Prefixed with feature/
• Bugfix branches: Prefixed with bugfix/

The workflow is triggered by pull requests targeting the main branch. You want the workflow run's name to reflect the type of work being integrated, the specific branch it is coming from, and the name of the user who initiated the run: that would help quickly identify the nature of the workflow run when looking through the Actions tab in the GitHub repository.

name: Integration CI

on:
  pull_request:
    branches: [ main ]

# Dynamically set the run name to include the type of branch (feature or bugfix), branch name, and the user
run-name: "${{ contains(github.head_ref, 'feature/') && 'Feature' || contains(github.head_ref, 'bugfix/') && 'Bugfix' || 'Update' }}: ${{ github.head_ref }} by @${{ github.actor }}"

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Setup Node.js
      uses: actions/setup-node@v2
      with:
        node-version: '14'
    - name: Install dependencies
      run: npm install
    - name: Run tests
      run: npm test

That workflow is configured to trigger on pull requests targeting the main branch.

The run-name field uses expressions to dynamically construct the run name based on the branch type (feature/ or bugfix/), the branch name, and the GitHub username of the actor who initiated the run.

• If the branch is a feature branch (prefixed with feature/), the run name starts with "Feature".
• If the branch is a bugfix branch (prefixed with bugfix/), the run name starts with "Bugfix".
• For branches that do not match these prefixes, it defaults to "Update".
• The run name also includes the branch name (github.head_ref) and the username of the actor who initiated the run (github.actor).

The example includes a simplified job called build-and-test that sets up a Node.js environment, installs dependencies, and runs tests. That part is standard for many JavaScript projects but can be customized based on your project's needs.

Context:

The run-name attribute in GitHub Actions workflows allows you to dynamically set the name of each workflow run. That feature is particularly useful for distinguishing between runs at a glance in the GitHub UI, especially in complex workflows triggered by various events or requiring specific context to understand the run's purpose or origin.

It supports expressions, enabling dynamic run names based on the context of the trigger event, inputs, or any other relevant information available in the GitHub context.
You can use context and expressions to tailor run names to reflect:

• The type of trigger (push, pull_request, workflow_dispatch, etc.)
• The branch name or tag
• The actor initiating the run
• Custom inputs for manual triggers
• Any combination of available context information to form a meaningful name

That will:

• makes it easier to navigate and understand the purpose of each run in the Actions tab.
• helps maintainers quickly identify the type of work and the initiator of workflow runs, aiding in troubleshooting and prioritizing workflow reviews.
• allows teams to systematically manage and monitor their CI/CD pipelines, especially in repositories with frequent and varied types of contributions.

In the case of a PR, as mentioned in the comments by Vytux, you can try a ternary-like expression that uses github.head_ref when it is available and falls back to github.ref_name (which is available for push events) when it is not.

name: Integration CI

on:
  pull_request:
    branches: [ main ]
  push:
    branches: [ main ]

# Use github.head_ref if available, otherwise fall back to github.ref_name.
run-name: "${{ github.head_ref != '' ? github.head_ref : github.ref_name }}: by @${{ github.actor }}"

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Setup Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '14'
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test

Use the /repos/{owner}/{repo}/actions/workflows/{workflow_id}/runs endpoint to list the runs of a given workflow ID in a given repository.

For example, to get all of the runs of the CI job for the rust-lang/rust repository, use https://api.github.com/repos/rust-lang/rust/actions/workflows/817415/runs.

This is now available in organization settings > Runners > GitHub-hosted runners. URL looks like https://github.com/organizations//settings/actions/hosted-runners. Screenshot: