我在GitHub上创建了一个仓库，其中包含一个 environment.yml 文件以及若干Jupyter notebook .ipynb 文件，mybinder.org的网络服务能够成功拉取并加载其中的内容。

接下来我尝试在我的仓库中设置一个 repo2docker GitHub Action，用于在每次向仓库提交时自动构建一个Docker镜像并将其缓存到mybinder.org。我通过创建一个 /.github/workflows/binder.yml 文件来实现，内容完全按照repo2docker文档 这里 的建议编写：

name: Binder
on: [push]

jobs:
  Create-MyBinderOrg-Cache:
    runs-on: ubuntu-latest
    steps:
    - name: cache binder build on mybinder.org
      uses: jupyterhub/repo2docker-action@master
      with:
        NO_PUSH: true
        MYBINDERORG_TAG: ${{ github.event.ref }} # This builds the container on mybinder.org with the branch that was pushed on.

然而GitHub工作流执行失败，显示以下错误信息：

Triggering Image Build on mybinder.org
    % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                   Dload  Upload   Total   Spent    Left  Speed

    0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
    0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  curl: (60) SSL certificate problem: self-signed certificate
  More details here: https://curl.se/docs/sslcerts.html

  curl failed to verify the legitimacy of the server and therefore could not
  establish a secure connection to it. To learn more about this situation and
  how to fix it, please visit the webpage mentioned above.

我真的不知道该如何解决这个问题，而repo2docker的 action文档也没有提及SSL证书。这里有人能否指引我走向解决此问题的正确方向？

编辑

在其他站点对该问题的交叉发帖如下：

• https://discourse.jupyter.org/t/ssl-certificate-problem-during-repo2docker-github-action-for-building-cache-for-mybinder-org/38529
• https://github.com/jupyterhub/repo2docker-action/issues/136

解决方案

curl: (60) 错误表示当前环境不信任证书链（通常是由于自签名或缺失CA证书所致），并非端点本身无效。

在GitHub Actions中，这通常发生在repo2docker使用的基础镜像缺失或CA证书过期。

需要检查的事项：

• 确保在构建环境中安装并保持CA证书的最新状态：

apt-get update && apt-get install -y ca-certificates && update-ca-certificates

• 如果repo2docker从你的仓库构建，请核实你的Dockerfile或运行环境没有覆盖证书路径，或使用了没有CA捆绑包的最小基础镜像。
• 如果执行环境位于代理或VPN之后，SSL检查也可能导致验证失败。

作为快速诊断，

run curl -v

在失败的步骤中检查所呈现的证书链。

如果你能提供失败步骤的日志以及相关的Dockerfile或构建配置，就应该能够准确定位信任断裂的具体位置。