我完全懂你的痛点——明明已经按指南把GitLab和CodePipeline通过Webhook+Lambda+S3对接好了，但源阶段显示的S3版本ID完全没实际参考价值，而你的ZipDlLambda已经拿到了GitLab的commit_id和commit_url，咱们可以从这几个方向调整来实现需求：

方案1：给S3对象加Git元数据，注入Pipeline执行上下文（最快实现） #

既然Lambda已经能拿到Commit信息，咱们可以在Lambda把代码包上传到S3时，给这个S3对象添加自定义元数据，同时把Commit ID传入CodePipeline的执行上下文，这样就能在Pipeline页面直接看到：

1. 修改ZipDlLambda的S3上传逻辑，添加Git相关元数据：

# 假设你用boto3操作S3，在put_object时加入Metadata参数
import boto3

s3 = boto3.client('s3')
s3.put_object(
    Bucket='你的S3存储桶名称',
    Key='代码包的存储路径/xxx.zip',
    Body=生成的zip文件内容,
    Metadata={
        'git-commit-id': 从GitLab Webhook拿到的commit_id,
        'git-commit-url': 从GitLab Webhook拿到的commit_url
    }
)

2. 触发CodePipeline时传入执行上下文，如果你的Lambda负责启动Pipeline执行，调用start_pipeline_execution时加上自定义变量：

codepipeline = boto3.client('codepipeline')
codepipeline.start_pipeline_execution(
    name='你的CodePipeline名称',
    executionContext={
        'variables': {
            'GIT_COMMIT_ID': commit_id,
            'GIT_COMMIT_URL': commit_url
        }
    }
)

这样打开CodePipeline的执行详情页，就能在「执行上下文」板块看到这些自定义变量，直接获取Commit ID和链接。

方案2：自定义CodePipeline源动作（和GitHub对接体验一致） #

如果想让源阶段直接显示GitLab的Commit ID作为版本号，就像GitHub对接那样，可以创建一个自定义源动作类型：

• 写一个专门的Lambda函数，处理CodePipeline的源请求：拉取GitLab代码、提取Commit信息，然后把Commit ID作为版本号返回给CodePipeline
• 在AWS CodePipeline控制台注册这个自定义动作类型
• 替换原来的S3源阶段为这个自定义源动作
  这样CodePipeline的源阶段就会直接显示GitLab的Commit ID，完全复刻GitHub的对接体验。

方案3：调整Webhook触发逻辑（简化中转） #

如果你的GitLab Webhook可以直接触发CodePipeline（跳过Lambda中转S3的步骤），可以在Webhook的payload里提取Commit ID，然后在CodePipeline的源阶段配置中，指定版本号来自Webhook payload的对应字段。不过这个方案需要调整现有对接逻辑，适合还没完全固化流程的场景。

总结下来，方案1是最快落地的，修改现有Lambda代码就能看到效果；如果追求和GitHub完全一致的显示体验，方案2是最彻底的解决办法。

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