标签: github-actions

我正在使用 GitHub Actions 进行 R CMD 检查（请参阅https://github.com/r-lib/actions）。

我想snapshot_file在testthat这种脚本中使用：

save_png <- function(code, width = 1000, height = 600) {
  path <- tempfile(fileext = ".png")
  grDevices::png(path, width = width, height = height)
  on.exit(dev.off())
  code
  
  path
}

set.seed(123)
df <- data.frame(y=rnorm(20),x=rnorm(20))

test_that("graphs are correct", {
  expect_snapshot_file(path = save_png(plot(df$y,df$x)), name = "plot1.png")
}

目前，错误将始终是： Adding new file snapshot "_snaps/gets-test1-example/plot1.png"。或者，如果我上传在我的笔记本电脑上生成的绘图，我会收到一个错误，它们是不同的（非常轻微）......

因为我知道快照测试很脆弱，所以我想到了两个选择：

• 删除在我的笔记本电脑上生成的 _snaps 文件夹中的所有快照文件，然后使用某种形式的 upload-artefact ( https://github.com/actions/upload-artifact ) 第一次上传快照 - 然后GitHub actions 有由同一台机器生成的东西来测试它（我在想类似每个操作系统的专用存储位置，其中现有文件首先加载到工作流机器然后检查）
• 跳过 GitHub Actions 上的所有 snapshot_files（使用 …

我有一个 GitHub 操作来运行我的 PowerShell 测试脚本。测试脚本在出现错误时输出“[ERROR]”，在出现警告时输出“[WARNING]”。 我想知道是否有任何关于突出显示的其他关键字的文档。GitHub 操作在 pwsh/PowerShell shell 中的“windows-latest”上运行。

我有很多工作流程.yaml 文件，它们的代码和逻辑非常相似。这是严重违反 DRY（不要重复自己）的行为。

理想情况下，我会创建一个on: workflow_dispatch:'包含一系列输入的工作流程。然后我通过其他工作流程来调用该工作流程。

如果上述想法不容易实现，那么 GitHub 工作流程的 DRY 选项是什么？

我正在使用 GitHub Action 进行一些自动化测试，我的应用程序是在 docker 中开发的。

name: Docker Image CI

on:
  push:
    branches: [ master]
  pull_request:
    branches: [ master]

jobs:

  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Build the Docker image
      run: docker-compose build

    - name: up mysql and apache container runs
      run: docker-compose up -d 

    - name: install dependencies
      run: docker exec  myapp php composer.phar install
  
    - name: show running container
      run: docker ps 


    - name: run unit test
      run: docker exec  myapp ./vendor/bin/phpunit 

在“显示正在运行的容器”步骤中，我可以看到所有容器都在运行，但对于 MySQL，状态为（运行状况：正在启动）。因此，我的单元测试用例全部失败，因为它需要连接到 MySQL。请问有没有办法只有当MySQL容器状态健康时才启动单元案例？

我有一个简单的静态网站，我尝试使用 GitHub Actions 将其部署为 Azure 静态 Web 应用程序（无框架）。我的目录结构是：

\xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 .github/workflows/\n\xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 css/\n\xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 img/\n\xe2\x94\x9c\xe2\x94\x80\xe2\x94\x80 js/\n\xe2\x94\x9c index.html\n

当我推送到 GitHub 存储库时，Azure 静态 Web 应用 CI/CD 操作将启动生成和部署作业。在 .github/workflows 目录中的 YAML 配置文件中，我为存储库/构建配置设置了以下内容：

app_location: "/"    # The app source code is in the root directory for the repo\napi_location: ""     # There is no API that needs to be configured\noutput_location: "/" # my index.html file is in the root directory for the repo\n

但是，我在构建和部署作业中收到以下错误：

\n

无法在应用程序工件文件夹 (/) 中找到默认文件。有效\n默认文件：index.html、Index.html。如果您的应用程序包含\n纯静态内容，请验证工作流文件（位于 .github/workflows 中）中的变量“app_location”\n是否指向应用程序的根目录。

\n

当我指定了 …

我正在尝试使用 GitHub Actions 部署我的 Elastic Beanstalk 应用程序（用于 CD 目的）。在运行负责部署的作业之前，我正在构建并推送应用程序在 DockerHub 上运行所需的 docker 映像。

我面临的问题是，在从 GitHub（GitHub Actions YAML 文件）构建和运行图像后遇到Permission Denied错误，而在本地构建和运行图像时却没有遇到错误。

我的 GitHub Actions yml 文件、Dockerfile 和 sh 文件如下所示：

# .github/workflows/deploy-to-staging.yml
name: Deploy to Staging

on:
  push:
    branches: [ master ]

jobs:
  deploy-to-staging:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      # Login to DockerHub
      - name: Docker Login
        uses: docker/login-action@v1.8.0
        with:
          username: ${{secrets.DOCKERHUB_USERNAME}}
          password: ${{secrets.DOCKERHUB_TOKEN}}
          logout: true
      # build, tag and push Nginx image to DockerHub
      - name: Build nginx image …

我有一个 GitHub所需的状态检查，每次打开/编辑/重新打开/同步到 master 时都会执行该状态检查。

操作本身已成功执行，但是在 PR 窗口中，检查始终处于待处理状态：Expected \xe2\x80\x94 Waiting for status to be reported

我只有 1 个状态检查（以简化场景来重现案例），并在 master 的分支策略中进行检查。没有定义其他操作工作流程。

我的脚本是：

name: ValidateFlow\n\non:\n  pull_request:\n    types: [opened, edited, reopened, synchronize]\n    branches: \n      - master\nenv:\n  GITHUB_PR_NUMBER: ${{github.event.pull_request.number}}\n  \njobs:\n  ValidateFlow:\n    runs-on: ubuntu-latest\n    \n    steps:\n      - uses: actions/checkout@v2\n      \n      - name: Extract branch name\n        run: echo "PR_Branch_Name=${{ github.head_ref }}" >> $GITHUB_ENV      \n               \n      - name: Write to a file\n        run: |\n                git config --global user.name "my_username"\n                git …

我需要在 GitHub Actions 工作流程期间查看私有存储库。我正在使用结账操作，并遵循其自述文件：

1. 我创建了一个服务帐户，即一个仅用于 GitHub Actions 工作流程的单独 GitHub 帐户。
2. 我为服务帐户创建了一个 PAT（个人访问令牌），有权访问私有存储库和当前工作流存储库。
3. 我创建了一个秘密来存储 PAT 令牌。

现在，当我执行以下操作时，它不起作用：

- name: Checkout
  uses: actions/checkout@v2
  with:
    token: ${{secrets.MY_TOKEN}}

看来我没有git正确配置以允许它使用令牌。我的问题是：我应该或如何配置git config在上述步骤中使用令牌？

私人存储库是主存储库的依赖项。两个存储库都是 Rust 程序，使用 Cargo，因此我尝试使用相同的服务帐户首先检查主存储库。然后 Cargo 将检查私人仓库。

我想在 github 操作的 docker 构建中设置 gcloud sdk。因此我需要将 service-account.json 传递给 dockerfile。

我知道我可以将构建参数传递给 dockerfile，当然我可以在这里传递 Github 秘密。但现在我听说了 Docker 秘密，它阻止了在 docker 日志中读取秘密。真的必须为秘密提供一条道路吗？我不想将秘密保存在存储库中，我更愿意使用 github 秘密。

那么，有什么想法可以将 gh 操作中的 github 秘密传递给 dockerfile 进行构建的最佳和最安全的方法吗？

我的帐户在另一个用户的存储库上具有“协作者”状态。当我从分支上的分支创建（或添加提交）到上游存储库的主分支的 PR 时，操作/工作流程不会运行。我不是该存储库的第一次贡献者。

我的理解是，来自分叉的 PR 在未经批准的情况下不会运行（根据这些文档），但我不清楚由所有者在存储库中添加为“协作者”是否应该跳过批准的需要。此外，默认设置似乎是仅首次贡献者才需要批准。

我确实看到我的分叉中的每次提交都会启动工作流程运行，因此我知道我的工作流程是有效的。我只需要工作流也在上游存储库上运行，以便运行的状态/结果显示在“拉取请求”页面上。

造成这种情况的可能原因有哪些？

作为参考，这里是我希望在每次推送时运行的工作流程的前几行。

name: CI

on: [ push ]

jobs:
    ... etc ...