如何在github action服务容器中运行命令？

Question

我正在使用minio创建一个类似于s3的对象存储服务器，并且我想在ci cd过程中针对该服务器测试一些代码。

使用Github操作，我试图在工作流文件中添加minio作为服务，但由于minio需要一个命令和一些参数，所以我无法使用此机制实际运行它。

这是我的ci.yml中相关配置的一部分：

minio-container:
runs-on: ubuntu-latest
container: python:3.8.2

services:
  minio:
    image: minio/minio:latest
    ports:
      - 9000:9000
    env:
      MINIO_ACCESS_KEY: XXXX
      MINIO_SECRET_KEY: XXXXX

我读了一点，发现github在后台运行docker crate service [OPTIONS] IMAGE_NAME，但我还需要能够运行docker create service [OPTIONS] IMAGE_NAME COMMAND [ARGS]

如果这还没有实现，我还可以尝试哪些其他选项？

谢谢,

或

Answer 1

快速浏览一下Github Actions文档，这一点还不受支持。你可以通过使用Bitnami的Minio镜像很容易地解决这个问题。

我相信像这样的东西应该是有效的：

    services:
  minio:
    image: bitnami/minio:latest
    env:
      MINIO_ACCESS_KEY: minio
      MINIO_SECRET_KEY: minio123
    ports:
      - 9000:9000
    options: --name minio-server

Answer 2

仔细一看，有一种方法。但在我开始之前，我尝试了几个想法。首先，我认为可以将包含源代码的目录挂载到容器中，并通过指定--entrypoint选项来运行其中一个项目文件(脚本)，但服务是在git clone之前启动的。然后我想也许我可以向容器传递一个命令，但是不，这是不可能的。我考虑的第三个选项是通过环境变量将命令传递给镜像附带的某个可执行文件，假设是shell。但是shells可以采用脚本的路径，而不是命令(ENV变量)。然后我想，“让服务消亡吧，”我只需要在克隆存储库之后执行restart the container。但与之相比，这并没有带来什么好处。

“只需手动创建容器即可。”我就是这么做的：

.github/workflows/django.yml

...
jobs:
    build:
        runs-on: ubuntu-latest
        container: python:3.5-alpine3.12
        steps:
            - uses: actions/checkout@v2
            - run: apk add expect && unbuffer ./create-cypress-container.sh
...

create-cypress-container.sh

#!/bin/sh -eux
apk add docker jq
network=$(docker inspect --format '{{json .NetworkSettings.Networks}}' `hostname` \
  | jq -r 'keys[0]')
docker pull -q cypress/base:12
docker run \
  -v /home/runner/work:/__w \
  -w "$GITHUB_WORKSPACE" \
  --name cypress \
  --network "$network" \
  -d \
  cypress/base:12 sh -xc 'ls && whoami && pwd'
sleep 10
docker ps
docker logs cypress

使用以下选项启动作业容器(请参见Initialize containers > Starting job containeir)：

...
--workdir /__w/PROJECT_NAME/PROJECT_NAME
-v "/home/runner/work":"/__w"
...

和环境变量：

...
GITHUB_WORKSPACE='/__w/PROJECT_NAME/PROJECT_NAME'
...

/__w/PROJECT_NAME/PROJECT_NAME是您的存储库被克隆的地方。

附注:话虽如此，我将在单独的作业中运行前端和后端测试，这应该会简化问题，并可能消除手动启动容器的需要。