我刚好踩过这个坑，结合GitLab CI/CD和GitHub的Webhook能力，完全能实现你要的效果——当第三方GitHub仓库更新时，自动构建带你自定义修改的镜像，还能让watchtower正常识别更新。下面是具体步骤：

1. 准备你的GitLab专属项目 #

先在GitLab上新建一个项目，用来存放所有自定义相关的内容：

• 自定义Dockerfile（基于原仓库的镜像或代码做修改）
• .gitlab-ci.yml配置文件
• 你需要添加的插件、配置文件等自定义资源

举个Dockerfile的例子（假设原镜像来自Docker Hub）：

# 拉取原仓库的最新官方镜像
FROM author/repo:latest

# 你的自定义操作：比如安装特定插件
RUN apt-get update && apt-get install -y your-plugin-name
# 复制自定义配置文件到镜像内
COPY ./your-custom-config.conf /target/path/

2. 配置GitHub Webhook触发GitLab Pipeline #

因为原仓库在GitHub，我们需要让GitHub在代码更新时主动通知GitLab触发构建：

• 获取GitLab触发URL：打开你的GitLab项目，进入「Settings」→「CI/CD」→「Pipeline triggers」，创建一个触发令牌（token），然后拼接成触发URL：https://gitlab.example.com/api/v4/projects/<项目ID>/trigger/pipeline?token=<触发令牌>&ref=<你的分支名>
• 在GitHub配置Webhook：打开原GitHub仓库的「Settings」→「Webhooks」→「Add webhook」，把上面的GitLab触发URL填到「Payload URL」，「Content type」选application/json，事件选择「Just the push event」（如果关注版本发布，也可以选「Release」事件），最后保存即可。

这样原仓库一有代码推送，就会自动触发你的GitLab构建流程。

3. 编写.gitlab-ci.yml实现自动构建推送 #

核心是让CI/CD完成「拉取最新原镜像/代码→构建自定义镜像→推送到镜像仓库」的完整流程。下面以推送到GitLab Container Registry为例（换成Docker Hub只需调整登录命令）：

stages:
  - build
  - push

variables:
  # 自定义镜像的完整名称
  CUSTOM_IMAGE: $CI_REGISTRY_IMAGE/your-custom-image
  # 原GitHub仓库地址（如果需要基于代码构建而非镜像，就用到这个）
  ORIGINAL_REPO: https://github.com/AUTHOR/REPO.git

build-image:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  before_script:
    # 登录GitLab镜像仓库（推Docker Hub就换成docker login -u $DOCKER_HUB_USER -p $DOCKER_HUB_PASS）
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    # 可选：如果需要基于原仓库代码构建，先拉取最新代码
    # - git clone $ORIGINAL_REPO ./original-code
  script:
    # 获取原仓库最新commit哈希，用作镜像标签（也可以用原仓库的release tag）
    - COMMIT_HASH=$(git ls-remote $ORIGINAL_REPO HEAD | awk '{print $1}')
    # 构建镜像，同时打latest和commit哈希两个标签
    - docker build -t $CUSTOM_IMAGE:latest -t $CUSTOM_IMAGE:$COMMIT_HASH .
  only:
    # 只允许Webhook触发的Pipeline执行此任务
    - triggers

push-image:
  stage: push
  image: docker:latest
  services:
    - docker:dind
  dependencies:
    - build-image
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - COMMIT_HASH=$(git ls-remote $ORIGINAL_REPO HEAD | awk '{print $1}')
    # 推送两个标签的镜像到仓库
    - docker push $CUSTOM_IMAGE:latest
    - docker push $CUSTOM_IMAGE:$COMMIT_HASH
  only:
    - triggers

关键细节说明： #

• 版本标签策略：同时打latest和原仓库commit哈希标签，既方便watchtower识别更新（latest镜像ID每次都会变），也能通过哈希追溯对应原仓库的版本。
• 敏感变量管理：把CI_REGISTRY_PASSWORD、DOCKER_HUB_PASS这类敏感信息存到GitLab项目的「Settings」→「CI/CD」→「Variables」里，绝对不要硬写在配置文件中。
• 触发限制：通过only: triggers确保只有GitHub Webhook触发的Pipeline才会执行构建，避免你自己修改项目代码时误触发。

4. 兼容watchtower自动更新 #

watchtower默认会检查镜像仓库中latest标签的镜像是否有更新，只要你每次推送的latest镜像是全新的（镜像ID不同），watchtower就会自动拉取并重启对应容器。如果你用了commit哈希或版本标签，也可以在启动watchtower时加上--include-restarting参数，或者让容器使用带版本的标签，watchtower一样能识别到更新。

可选优化 #

• 构建层缓存：在.gitlab-ci.yml中添加Docker层缓存配置，能大幅加快后续构建速度，比如用GitLab的cache关键字或者第三方缓存服务。
• 定期兜底检查：怕Webhook失效的话，可以用GitLab的「Pipeline Schedules」设置每天定时触发一次构建，确保不会错过原仓库的更新。
• 镜像验证：在构建后加一个测试阶段，运行镜像验证自定义功能是否正常，再推送镜像到仓库。

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