Gatsby很好，但它没有提供很多（或者说，没有提供任何）调度内容发布的方式。今天，我将向你展示我如何使用Github Actions安排我的Gatsby博客文章。

我的工作流程

我在本地开发一个新的博文分支，并与我博客github.com仓库的上游分支保持同步。当我写完后，我会从该分支创建一个 PR，放到main 。最后，我在PR中加入以下描述，它将告诉我们即将开发的动作何时合并该分支。

/schedule 2021-05-04

这条说明告诉行动在2021年5月4日将该分支合并到main 。我的Gatsby博客通过Github集成部署到Netlify，所以一旦这个新的分支被合并到main ，一个新的构建就会被启动和部署!

行动

要在你的应用程序中添加这个动作，在你的项目根部创建一个/.github/workflows 目录。在该目录中，创建一个名为merge-schedule.yml 的文件，内容如下。

/.github/workflows/merge-schedule.yml

name: Merge Schedule
on:
  pull_request:
    types:
      - opened
      - edited
      - synchronize
  schedule:
    - cron: 0 * * * *

jobs:
  merge_schedule:
    runs-on: ubuntu-latest
    steps:
      - uses: gr2m/merge-schedule-action@v1
        with:
          merge_method: squash
          time_zone: 'America/New_York'
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

请注意，这个工作流程是由优秀的merge-schedule-action动作驱动的--你甚至可能会注意到我的yaml文件与他们给出的例子惊人地相似

你可能对这个文件有一个疑问，那就是它看起来需要一个GITHUB_TOKEN secret。实际上不需要担心这个秘密，它是在Github行动环境中自动提供的。

自定义你的配置

你可能想根据自己的喜好来定制这个yaml文件。按原样，它每小时运行一次，但你可以选择只在一天中的某个时间发布帖子。你可以通过改变cron 属性来调整时间表。如果你不熟悉cron job sytax，可以看一下crontab guru!

还要注意的是，time_zone 属性是为"America/New_York" 设置的；你可能想为你自己的时区调整这个。

弊端。冗长的日期规范

我安排/发布我的文章的方式的一个缺点是，我最终在三个不同的地方指定了发布日期。

1. 首先，我把它放在我的博客文章的frontmatter ，因为那是唯一面向用户的发布日期的指示。
2. 接下来，我在我的文章的分支名称中包括日期。例如，你现在看到的这篇文章是在一个叫做2021-05-19-scheduling-gatsby-posts 的分支上开发的。请注意，这并不是工作流程的必要部分，它只是帮助我轻松地分辨出我所安排的帖子的日期。
3. 最后，正如之前所讨论的，我在PR的描述中加入了调度日期（例如：/schedule 2021-05-19 ）。

重写三次日期并不是什么大问题，但确实感觉效率略低，而且留下了出错的空间。

总结

我希望这能帮助你弄清楚如何安排你的Gatsby帖子!