Terraform GitLab Provider改commit_message加[DELETE]是否为预期行为

Terraform GitLab Provider 修改资源commit_message配置时自动添加[DELETE]标记、不使用新配置提交信息的现象不属于预期行为，是资源逻辑缺陷导致的异常。

gitlab-repository-files_gitlab_repository_file是早期社区独立维护的第三方GitLab文件资源，并非GitLab官方维护的Provider原生资源：

• 旧版本该资源的状态判定逻辑存在缺陷，会将commit_message字段的变更识别为需要销毁旧资源、重建新资源的触发条件
• 资源销毁操作的提交信息为硬编码逻辑：固定拼接[DELETE]: 前缀加上一次状态存储的旧commit_message值，不会读取新配置的提交信息
• 逻辑异常会导致后续新资源创建步骤未正确执行，最终GitLab端仅留下带[DELETE]标记的旧提交，新配置的commit信息完全不生效。

• 优先替换为官方GitLab Provider（源地址gitlabhq/gitlab）内置的gitlab_repository_file资源。官方资源逻辑中，commit_message属于操作类参数，修改该字段不会触发资源强制重建，所有创建、更新操作都会直接使用配置的提交信息，不会自动追加任何自定义前缀标记。
  官方资源基础配置示例：

  terraform {
    required_providers {
      gitlab = {
        source  = "gitlabhq/gitlab"
        version = ">= 16.0"
      }
    }
  }
  
  resource "gitlab_repository_file" "this" {
    project        = gitlab_project.foo.id
    file_path      = "meow.txt"
    branch         = "main"
    content        = base64encode("hello world")
    author_email   = "meow@catnip.com"
    author_name    = "Meow Meowington"
    commit_message = "[ci skip] terraform templating commit\n\nJob URL: ${local.gitlab_configuration_details.pipeline_job_url}"
  }
  

• 若暂时无法替换资源类型，将当前使用的第三方gitlab-repository-files provider升级到最新补丁版本。该缺陷在后续社区迭代中已修复：调整了资源重建判定规则，commit_message变更不会再触发销毁重建逻辑，执行更新时会直接读取配置的最新提交信息。
• 临时应急方案：若短时间内既不能替换资源也不能升级Provider，可在修改commit_message的同时，对content字段做一次无业务影响的微调（比如末尾追加空行后再还原），强制Provider走文件内容更新流程，绕过错误的销毁重建判定。该方案稳定性较差，不推荐长期使用。

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