GithubActions-在一个操作完成后触发另一个操作

First, you are mixing terms here. According to GitHub Actions documentation a single YAML file is called a workflow (not an action) and consists of jobs. Jobs contain a sequence of steps (including actions) that are executed one after another. A particular workflow execution is called a run. Having that in mind lets go the questions.

How could the message workflow be triggered after build workflow is completed?

You can use GitHub API to trigger a webhook event called repository_dispatch (only for the base branch) or workflow_dispatch. This can be easily done using a dedicated Repository Dispach action in your build workflow.

Is it possible to get the result of the build workflow?

Yes, the result of the workflow run can be obtained using given GitHub API

But if you only want to send the build result notification of the currently executed workflow you don't need to create a separate workflow and trigger it from the parent. You can use dedicated Slack actions or e-mail actions.

How could the message action be triggered after build action is completed?

This should now (August 2020) be possible with "GitHub Actions improvements for fork and pull request workflows"

Another frequently-requested feature for Actions is a way to trigger one workflow based on the completion of another workflow.
For example, you may want to take the results of a CI workflow and run some further analysis.

The new workflow_run event enables you to trigger a new workflow when one or more workflows are requested or completed.
Runs triggered by the workflow_run event always use the default branch for the repository, and have access to a read/write token as well as secrets.
As an example, as a maintainer you could set up a workflow that takes the artifacts generated by the pull request workflow, do some analysis, and post comments back to the pull request.
This event is also available as a web hook.

you can try in step 2 the following directive:

needs: step-1-job-name

just after job name

There are 2 options of doing this:

1. Use a second job inside the same workflow.yml together with the needs keyword
2. Create a separate notify.yml workflow that uses the workflow_run event as a trigger

1. Same workflow, separate job with needs keyword

In your workflow.yml file you simply define two jobs like this (leveraging the needs: build configuration in the second job):

name: CI build and notify


on: [push]


jobs:
build:
runs-on: ubuntu-latest


steps:
- uses: actions/checkout@v2
    

- name: Deploy Docker image to Google Cloud Run
run: ...


notify:
needs: build
runs-on: ubuntu-latest


steps:
- uses: actions/checkout@v2


- name: Notify Slack and send eMail
run: ...

As the docs state, the second notify job will only start if the first build job succeeded:

Identifies any jobs that must complete successfully before this job will run.

Here's a screenshot of how this approach can look like practically from my own project (I have a second publish-snapshot job instead of your notify job - but the concept stays the same):

There's also a way to always let the notify job run, even if the build job failed. You have to enhance the needs with a if: always() configuration then.

2. Separate workflow, using the workflow_run event as a trigger

Using the workflow_run event as a trigger we end up having 2 separate GitHub Actions workflow yaml files:

build.yml

name: CI build


on: [push]


jobs:
build:
runs-on: ubuntu-latest


steps:
- uses: actions/checkout@v2


- name: Deploy Docker image to Google Cloud Run
run: ...

notify.yml

name: CI notify


# Only trigger, when the build workflow succeeded
on:
workflow_run:
workflows: ["CI build"]
types:
- completed


jobs:
notify:
runs-on: ubuntu-latest


steps:
- uses: actions/checkout@v2


- name: Notify Slack and send eMail
run: ...

A crucial point here is that the name: CI build definition of the first yaml file must exactly match the workflow_run: workflows: ["CI build"] definition in the second yaml file. Another point is that this approach needs to be done on the default branch (which is mostly main or master) as the docs state:

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

Here's also a full example project using the 1st option if you're interested.

The best method i've found for reusable workflows in the same repository is https://docs.github.com/en/actions/using-workflows/reusing-workflows

In the workflow you want to re-use (let's call it wf1):

# wf1.yml
on:
workflow_call:

In the workflow you want to call wf1 from (let's call this wf2)

# wf2.yml
jobs:
call-wf1:
uses: ./.github/workflows/wf1.yml
secrets: inherit

In order to get data from one workflow to another, check out https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-outputs-from-a-reusable-workflow.

First, set up your reusable workflow to output the data:

name: Reusable workflow


on:
workflow_call:
# Map the workflow outputs to job outputs
outputs:
firstword:
description: "The first output string"
value: $\{\{ jobs.example_job.outputs.output1 }}
secondword:
description: "The second output string"
value: $\{\{ jobs.example_job.outputs.output2 }}


jobs:
example_job:
name: Generate output
runs-on: ubuntu-latest
# Map the job outputs to step outputs
outputs:
output1: $\{\{ steps.step1.outputs.firstword }}
output2: $\{\{ steps.step2.outputs.secondword }}
steps:
- id: step1
run: echo "::set-output name=firstword::hello"
- id: step2
run: echo "::set-output name=secondword::world"

Now use it in the calling workflow:

name: Call a reusable workflow and use its outputs


on:
workflow_dispatch:


jobs:
job1:
# local repo
# uses: .github/workflows/called-workflow.yml@v1
# other repo
uses: octo-org/example-repo/.github/workflows/called-workflow.yml@v1


job2:
runs-on: ubuntu-latest
needs: job1
steps:
- run: echo $\{\{ needs.job1.outputs.firstword }} $\{\{ needs.job1.outputs.secondword }}