用于SpeedCurve的Netlify构建插件

Netlify hosted their JAMStack Conf in San Francisco this past Wednesday. Quibbles with the JAMStack name aside, there were some great talks in the schedule and they’ve started to fill up my watch later list.

Netlify于上周三在旧金山举办了他们的JAMStack Conf 。 除了JAMStack的名字之外，日程安排中还进行了一些精彩的演讲，它们已经开始填补我以后的观看列表。

One thing that Netlify announced during the event was their new build plugins functionality. Netlify’s build process now exposes different events during the build and deploy lifecycle that you can use as hooks to attach certain functionality to. The simplest way to do that at any sort of scale is to create a build plugin that you can then install for any site you may want to use it.

Netlify在活动期间宣布的一件事是其新的构建插件功能 。 Netlify的构建过程现在在构建和部署生命周期中公开了不同的事件，您可以将它们用作附加某些功能的挂钩。 进行任何规模扩展的最简单方法是创建一个构建插件，然后可以将其安装到可能要使用它的任何站点。

It’s not all that different from any other sort of build process, I suppose, but it does give Netlify some continuous integration functionality which is nice.

我想这与其他任何类型的构建过程都没有什么不同，但是它确实为Netlify提供了一些不错的连续集成功能。

I really like Netlify, and I really like SpeedCurve so I thought building a SpeedCurve plugin for Netlify would be a fun way to play around with the new feature.

我真的很喜欢Netlify，也很喜欢SpeedCurve，所以我认为为Netlify构建SpeedCurve插件将是一种有趣的新功能。

进行设定 (Getting setup)

The first step was signing up for the private beta and getting access to build plugins in the first place.

第一步是注册私有Beta，并首先获得构建插件的访问权限。

There wasn’t much to do at all to get started playing with the build lifecylcle and plugins locally. I had to make sure I had a netlify.yml configuration file for my site and use the latest version of the Netlify CLI, and that was about it.

开始在本地使用构建生命周期和插件完全没有什么可做的。 我必须确保我的站点有一个netlify.yml配置文件，并使用最新版本的Netlify CLI，仅此而已。

To enable build plugins remotely, in the live Netlify Account, requires a teeny, tiny bit of setup. I’m afraid I can’t tell you that or the Netlify team will probably lock me out of my account and send Phil Hawksworth over to “tie up the loose ends” or something.

要在实时Netlify帐户中远程启用构建插件，需要进行一些微小的设置。 恐怕我无法告诉您，否则Netlify团队可能会将我拒之门外，并派遣Phil Hawksworth进行“绑扎”。

What I will say is that, in addition to the setup they suggested, I had to also change my build image from Ubuntu Trusty 14.04 (their legacy build image) to Ubuntu Xenial 16.04 (their current default). Don’t let the Linux names and versions scare you—these were the only two options and all I had to do was tick a radio button.

我要说的是，除了他们建议的设置之外，我还必须将构建映像从Ubuntu Trusty 14.04(其旧版构建映像)更改为Ubuntu Xenial 16.04(它们是当前默认设置)。 不要让Linux名称和版本吓到您-这是仅有的两个选择，我要做的就是勾选一个单选按钮。

构建插件 (Building the plugin)

Building the plugin itself turned out to be fairly painless. The build documentation was pretty helpful, though I mostly relied on Sarah’s post and the demo plugins she links to.

事实证明，构建插件本身非常容易。 尽管我主要依靠Sarah的帖子以及她链接到的演示插件，但是构建文档非常有帮助。

As I mentioned, there are a number of different lifecycle events that a plugin can hook into. In this case, my goal was to trigger a round of tests in SpeedCurve for each deploy, so it made sense to hook into the finally event. So, I created a folder for the plugin, made an index.js file, and setup the basic structure:

如前所述，插件可以挂接到许多不同的生命周期事件 。 在这种情况下，我的目标是在SpeedCurve中为每个部署触发一轮测试，因此有必要进入finally事件 。 因此，我为插件创建了一个文件夹，制作了一个index.js文件，并设置了基本结构：

module.exports = {
    async finally() {
        console.log('Preparing to trigger SpeedCurve tests');
    }
}

That little bit of code is all that’s really necessary to do something during the finally event of the lifecycle. To test it locally, you then add a plugins section to your netlify.yml configuration file:

在生命周期的finally事件中要做一些事情实际上只需要一点点代码。 要在本地对其进行测试，然后将一个plugins部分添加到netlify.yml配置文件中：

build:
  # this is basic configuration stuff telling
  # netlify where to publish to and what command
  # to run to build the site
  publish: dist
  lifecycle:
    build:
      - eleventy
plugins:
  # here's where we pull in the plugin
  speedcurveDeploy:
    type: ./plugins/netlify-plugin-speedcurve-deploy

What you call the plugin in the YAML file doesn’t really matter, as long as the path to the plugin is correct.

只要插件的路径正确，您在YAML文件中所谓的插件都没有关系。

So with that setup, I was able to use the Netlify CLI to confirm things were going to work alright by running:

因此，通过该设置，我可以使用Netlify CLI通过运行以下命令来确认一切正常：

netlify build --dry

That command spits out a bunch of information, but what’s relevant here is that it tells you what steps are going to run and what actions are attached to them.

该命令会吐出大量信息，但是这里相关的是它告诉您要执行哪些步骤以及对其执行了哪些操作。

The SpeedCurve API docs are pretty straightforward about how to trigger a deploy. Alongside some helpful options, there are two bits of information that are required: the API key and the Site ID.

SpeedCurve API文档非常简单地介绍了如何触发部署 。 除了一些有用的选项外，还需要两点信息：API密钥和站点ID。

The API key, at least, is sensitive information, so it made sense to put that in an environment variable (Netlify makes it easy to add them to your configuration in their admin area). I decided to also place the Site ID in an environment variable. I could’ve used the configuration feature in the YAML file, but it just seemed to be neater to put it all together in one spot for now.

API密钥至少是敏感信息，因此将其放在环境变量中是很有意义的(Netlify使得将其轻松添加到其管理区域中的配置中)。 我决定还将站点ID放在环境变量中。 我本可以使用YAML文件中的配置功能，但现在将它们全部放在一个位置似乎比较整洁。

Once again, I followed Sarah’s lead (never a bad idea) on neatly pulling in those variables into my plugin’s index.js file`:

再次，我跟随Sarah的领导(这绝不是一个坏主意)，将这些变量整齐地拉入插件的index.js文件中：

const {
    env: {
        //Your SpeedCurve API Key (Admin > Teams)
        SPEEDCURVE_API_KEY,
        SPEEDCURVE_SITE_ID
    }
} = require('process')

All that was left was to use that data to fire off the test. I pulled in node-fetch (because I find the ergonomics of the Fetch API very nice) and then used that to trigger the SpeedCurve tests from within the finally event already setup:

剩下的就是使用这些数据来启动测试。 我引入了node-fetch (因为我发现Fetch API的人体工程学非常好)，然后使用它从已经设置的finally事件中触发SpeedCurve测试：

fetch('https://api.speedcurve.com/v1/deploys', {
    method: 'POST',
    headers: {
        'Authorization': 'Basic ' + Buffer.from(SPEEDCURVE_API_KEY + ':' + 'x').toString('base64'),
        "Content-type": "application/json",
        "Accept": "application/json",
        "Accept-Charset": "utf-8"
    },
    body: JSON.stringify({
        site_id: SPEEDCURVE_SITE_ID
    })
})
.then(function (data) {
    if (data.status == 200) {
        console.log('SpeedCurve test submitted!');
    } else {
        console.log('SpeedCurve test couldn\'t be submitted. Status: ' + data.statusText);
    }
})
.catch(function (error) {
    console.log('Error: ', error);
});

And that was it. I ran a local build and things worked smoothly and, after tweaking the build image, a remote deploy worked on the first try as well. Now, each time I deploy a new version of the site, SpeedCurve will automatically run a series of tests so I can quickly see if I’ve changed anything from a performance perspective.

就是这样。 我运行了一个本地构建，并且工作顺利，并且在调整了构建映像之后，首次尝试也进行了远程部署。 现在，每次我部署该网站的新版本时，SpeedCurve都会自动运行一系列测试，以便从性能的角度快速查看是否更改了任何内容。

Better yet, because it’s built as a plugin, setting this up for any other Netlify sites I have will take only a minute or two.

更好的是，由于它是作为插件构建的，因此为我拥有的任何其他Netlify网站进行设置只需一两分钟。

瑕疵 (Imperfections)

There are a few things I’d like to tweak. The finally lifecycle event doesn’t technically fire after the deploy right now (something Netlify is working on fixing). That’s not a huge issue here because the Netlify build process is so fast that by the time SpeedCurve actually runs the tests, the new site has been deployed. Still, it should really be run after the deploy occurs just to be safe.

我想调整几件事。 从技术上讲， finally生命周期事件不会在当前部署后立即触发(Netlify正在努力修复)。 这不是什么大问题，因为Netlify的构建过程是如此之快，以至于SpeedCurve实际运行测试时，已经部署了新站点。 尽管如此，为了安全起见，它应该确实在部署之后运行。

Because it runs a little early, there’s also currently no way to get the deploy ID or anything else to make it a bit easier to track the change in SpeedCurve. I’d love to be able to pass back the deploy ID to the SpeedCurve API once it’s available. For now, SpeedCurve sees no title applied so it just uses the current date to identify the deploy.

由于它运行得较早，因此目前也无法获取部署ID或其他任何方法，以使其更容易跟踪SpeedCurve中的更改。 我希望能够将部署ID传递回SpeedCurve API。 目前，SpeedCurve认为没有应用标题，因此仅使用当前日期来标识部署。

None other than Sir Hawk Philsworth himself pointed me in the direction of some docs that I completely whiffed on. Turns out, you can grab the git commit hash using an environment variable, so I’ve updated the plugin to pass that along to SpeedCurve.

霍克斯•菲尔斯沃思爵士本人只是向我指出了我完全想起的一些文件的方向。 事实证明，您可以使用环境变量获取git commit哈希，因此我更新了插件以将其传递给SpeedCurve。

I think it’s still handy in its current form, so if you have access to the beta and want to give it a whirl, I’ve put the code up in a repo and added the plugin to npm as well if that’s your cup of tea (it does make using the plugin a hair easier, I think).

我认为目前的形式还是很方便的，因此，如果您可以访问Beta并想对其进行旋转，那么我已经将代码放在了一个 仓库中，并且如果您可以喝茶的话，也将其添加到了npm中 (我认为它确实使使用该插件变得容易一些)。

All in all though, Netlify build plugins seem pretty slick and straightforward. I’m a big proponent of baking basic optimizations and checks and balances into your build process, and Netlify’s build lifecycle gives us another place to hook into.

总而言之，Netlify构建插件看起来非常简洁明了。 我大力支持将基本优化以及检查和平衡纳入您的构建过程，而Netlify的构建生命周期为我们提供了另一个可供选择的地方。

I’ve got a few other plugins in mind already that I think will be pretty helpful. Now to find the time to build them.

我已经想到了其他一些插件，我认为这将非常有帮助。 现在开始寻找时间来构建它们。

翻译自: https://timkadlec.com/remembers/2019-10-18-netlify-speedcurve-build-plugin/