【问题标题】:Any way to have a common netlify.toml file for a single repository and multiple sites?有什么方法可以为单个存储库和多个站点提供一个通用的 netlify.toml 文件?
【发布时间】:2019-01-26 02:44:52
【问题描述】:

我正在寻找一种在 netlify 上定义两个站点构建的方法,它们来自同一个 repo,使用单个通用 netlify.toml。有可能吗?

我有一个名为 hugo-dream-plus 的 GitHub 存储库,为此我在 netlify 上配置了两个网站构建,即 dream-plus-postsdream-plus-cards。这两个构建共享相同的环境变量和大部分配置,除了构建命令:

hugo --config cards.toml     #For dream-plus-cards
hugo --config posts.toml     #For dream-plus-posts

我想知道是否有办法让我创建一个通用的netlify.toml 文件,因为这两个网站的两个版本的存储库都是相同的。

我已经使用 web UI 来分别配置每个构建,但是修改每个构建都很麻烦,这就是我更喜欢上述方案的原因。

我打算做的是在两个构建之间共享所有配置,除了构建命令,它会单独定义,如上所示。

【问题讨论】:

    标签: hugo netlify


    【解决方案1】:

    截至本答案发布之日,Netlify 不支持更改 netlify.toml 中的值的方法,因为它是在您构建之前读入的。除了标题和重定向,它们允许您在构建时更改。

    不支持在 netlify.toml 文件中直接使用环境变量作为值 ($VARIABLENAME)。

    然而

    您可以运行脚本命令并根据域或环境变量对其进行更改。 有一些设置可行。

    以下是我如何根据域名完成您想要的。

    netlify.toml

    [build]
      command = "node ./scripts/custom.js"
      publish = "public"
    

    scripts/custom.js

    const exec = require('child_process').exec;
    const site = process.env.URL || "https://example.com";
    const domain = site.split('/')[site.split('/').length - 1];
    
    let buildCommand;
    switch(domain) {
      case "dream-plus-posts.netlify.com":
        buildCommand = 'hugo --config posts.toml';
        break;
      case "dream-plus-cards.netlify.com":
        buildCommand = 'hugo --config cards.toml';
        break;
      default:
        throw `Domain ${domain} is invalid`;
    }
    
    async function execute(command){
      return await exec(command, function(error, stdout, stderr){
        if (error) {
          throw error;
        }
        console.log(`site: ${site}`);
        console.log(`domain: ${domain}`);
        console.log(stdout);
      });
    };
    
    execute(buildCommand);
    

    注意事项:

    • 我没有使用 Hugo 的这种方法测试标准输出到日志。子进程捕获输出并将其返回到标准输出中。
    • 我们不想捕获错误,因为我们希望我们的构建因错误而失败,所以这将导致退出代码不是 0
    • 您可以使用此解决方案内联其他命令(即“部署前的节点 ./scripts/custom.js && 一些其他命令”)
    • 您也可以只检查您设置的环境变量而不是域名

    【讨论】:

    • 谢谢。这对我来说是一个很好的参考,也解决了我的问题。我没想过要创建自定义构建脚本,从现在开始,我会这样做。
    • 很棒的脚本,谢谢!我最终选择了环境变量路由。
    猜你喜欢
    • 2020-11-26
    • 2020-02-03
    • 1970-01-01
    • 2015-10-12
    • 1970-01-01
    • 2021-11-15
    • 2019-10-11
    • 2018-04-01
    • 2018-12-01
    相关资源
    最近更新 更多