GitHub Actions Docker容器内npm install子目录权限问题排查

问题分析 #

GitHub Actions中使用自定义容器执行npm install时，postinstall脚本在子目录widgets创建node_modules时触发权限拒绝错误。移除container配置后流水线正常，且镜像在Bitbucket Pipelines中可正常运行，核心原因是GitHub Actions与Bitbucket Pipelines启动容器的用户权限策略不同：GitHub Actions默认使用容器内的非root用户（如node镜像的node用户），而挂载的仓库目录所有者为root，导致该用户无写入权限；Bitbucket Pipelines则默认以root用户运行容器，因此没有权限问题。

解决方案 #

方案1：在Workflow中指定以root用户运行容器 #

直接在container配置中添加user: root，让GitHub Actions用root身份执行所有步骤，避免权限问题：

修改后的workflow.yml片段：

jobs:
  install-and-cache-dependencies:    
    runs-on: ubuntu-latest
    container:
      image: houzy/frontend-builder:16.13.1
      env:
        NODE_OPTIONS: "--max_old_space_size=4096"
      user: root # 添加这一行
    steps:
      # 后续步骤不变

方案2：修改Dockerfile，适配GitHub Actions的非root用户策略 #

如果不想用root用户，可以调整Dockerfile，确保非root用户对工作目录拥有写入权限：

修改后的Dockerfile：

FROM node:16.13.0

# 创建工作目录并将权限赋予node用户
RUN mkdir -p /app && chown -R node:node /app
WORKDIR /app

# 原有的安装命令保持不变
RUN apt-get update; apt-get install -y gettext-base;
RUN echo 'deb http://dl.google.com/linux/chrome/deb/ stable main' > /etc/apt/sources.list.d/chrome.list
RUN wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add -
RUN set -x && apt-get update && apt-get install -y xvfb google-chrome-stable
RUN wget -q -O /usr/bin/xvfb-chrome https://bitbucket.org/atlassian/docker-node-chrome-firefox/raw/ff180e2f16ea8639d4ca4a3abb0017ee23c2836c/scripts/xvfb-chrome
RUN ln -sf /usr/bin/xvfb-chrome /usr/bin/google-chrome
RUN chmod 755 /usr/bin/google-chrome
RUN curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" && unzip awscliv2.zip && ./aws/install
RUN curl -O https://bootstrap.pypa.io/get-pip.py && python3 get-pip.py --user && ~/.local/bin/pip install --upgrade awsebcli

# 切换到node用户
USER node

方案3：在Workflow步骤中临时修复目录权限 #

如果不想修改镜像，也可以在checkout代码后添加一步，修改当前目录的所有者为容器默认的非root用户：

steps:
  - uses: actions/checkout@v3

  - name: Fix directory permissions
    run: sudo chown -R node:node . # node是容器内的默认非root用户，根据实际镜像调整

  # 后续步骤不变

说明 #

方案1最简单直接，但用root用户运行存在一定安全风险；方案2更符合容器最佳实践，推荐长期使用；方案3是临时 workaround，适合快速验证问题。

内容的提问来源于stack exchange，提问作者Nicu