如何将分支名称连接到github操作管道中的标记？

Question

我正在尝试使用github操作构建对接映像，如果发生了标记提交，以及在暂存和主分支上的推送或拉请求，则会触发该映像。我还使用kustomize来定制遗留清单，具体取决于提交。但是，每当我试图标记提交以触发管道时，都会出现问题，在提交带有此错误的kustomize.yaml部分，它将失败。

Run ad-m/github-push-action@master
Push to branch refs/tags/v0.3.8
To https://github.com/ahmedappout08/robo-demo.git
 ! [rejected]        HEAD -> v0.3.8 (already exists)
error: failed to push some refs to 'https://github.com/ahmedappout08/robo-demo.git'
hint: Updates were rejected because the tag already exists in the remote.
Error: Invalid exit code: 1
    at ChildProcess.<anonymous> (/home/runner/work/_actions/ad-m/github-push-action/master/start.js:29:21)
    at ChildProcess.emit (events.js:210:5)
    at maybeClose (internal/child_process.js:1021:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5) {
  code: 1
}
Error: Invalid exit code: 1
    at ChildProcess.<anonymous> (/home/runner/work/_actions/ad-m/github-push-action/master/start.js:29:21)
    at ChildProcess.emit (events.js:210:5)
    at maybeClose (internal/child_process.js:1021:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:283:5)

下面是Ci.yaml文件：

name: Docker

on:
  
  push:
    branches:
      - main
      - staging
    tags:
      - v*
  pull_request:
    branches:
      - main
      - staging

env:
  # TODO: Change variable to your image's name.
  IMAGE_NAME: robo-demo 
jobs:
  # Run tests.
  # See also https://docs.docker.com/docker-hub/builds/automated-testing/

  # Push image to GitHub Packages.
  # See also https://docs.docker.com/docker-hub/builds/
  push:
    # Ensure test job passes before pushing image.

    runs-on: ubuntu-latest


    steps:
      - name: Checkout master
        uses: actions/checkout@main

      

      - name: Build image
        run: docker build . --file Dockerfile --tag $IMAGE_NAME

      - name: Log into registry
        run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login docker.pkg.github.com -u ${{ github.actor }} --password-stdin
      
      - name: Push image tag
        if: ${{ github.ref == 'refs/heads/main' || github.ref == 'refs/heads/staging' }} == false
        run: |
          IMAGE_ID=docker.pkg.github.com/${{ github.repository }}/$IMAGE_NAME
          # Change all uppercase to lowercase
          IMAGE_ID=$(echo $IMAGE_ID | tr '[A-Z]' '[a-z]')
          # Strip git ref prefix from version
          #VERSION=$(echo "${{ github.ref }}" | sed -e 's,.*/\(.*\),\1,')
          VERSION=$GITHUB_SHA
          # Strip "v" prefix from tag name
          [[ "${{ github.ref }}" == "refs/tags/"* ]] && VERSION=$(echo $VERSION | sed -e 's/^v//')
          # Use Docker `latest` tag convention
          echo IMAGE_ID=$IMAGE_ID
          #echo VERSION=${GITHUB_REF##*/}
          echo VERSION=$GITHUB_SHA
          docker tag $IMAGE_NAME $IMAGE_ID:$VERSION
          docker push $IMAGE_ID:$VERSION
      - name: push image main & staging
        if: ${{ github.ref == 'refs/heads/main' || github.ref == 'refs/heads/staging' }}
        run: |
          IMAGE_ID=docker.pkg.github.com/${{ github.repository }}/$IMAGE_NAME
          # Change all uppercase to lowercase
          IMAGE_ID=$(echo $IMAGE_ID | tr '[A-Z]' '[a-z]')
          # Strip git ref prefix from version
          VERSION=$(echo "${{ github.ref }}" | sed -e 's,.*/\(.*\),\1,')
          # Strip "v" prefix from tag name
          [[ "${{ github.ref }}" == "refs/tags/"* ]] && VERSION=$(echo $VERSION | sed -e 's/^v//')
          # Use Docker `latest` tag convention
          echo IMAGE_ID=$IMAGE_ID
          echo VERSION=${GITHUB_REF##*/}
          docker tag $IMAGE_NAME $IMAGE_ID:$VERSION
          docker push $IMAGE_ID:$VERSION

      - name: congrats
        run: |
          echo "Image Built on Branch" ${GITHUB_REF##*/}
      - name: Setup Kustomize
        if: ${{ github.ref == 'refs/heads/main' || github.ref == 'refs/heads/staging' }} == false
        uses: imranismail/setup-kustomize@v1
        with:
          kustomize-version: "3.6.1"
      - name: Update Kubernetes resources
        if: ${{ github.ref == 'refs/heads/main' || github.ref == 'refs/heads/staging' }} == false
        run: |
          cd k8s-deployment/feature-version
          kustomize edit set image robo-image=docker.pkg.github.com/${{ github.repository }}/$IMAGE_NAME:$GITHUB_SHA
          cat kustomization.yaml
      - name: Commit files
        if: ${{ github.ref == 'refs/heads/main' || github.ref == 'refs/heads/staging' }} == false
        run: |
          git config --local user.email "action@github.com"
          git config --local user.name "GitHub Action" 
          git commit -am "Bump docker tag"
      - name: Push changes
        if: ${{ github.ref == 'refs/heads/main' || github.ref == 'refs/heads/staging' }} == false
        uses: ad-m/github-push-action@master
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          branch: ${{ github.ref }} 

我不知道如何解决这个问题来将提交推到连接到标记的分支本身，因为我需要在每一栋楼之后更新kustomize.yaml

Answer 1

我不知道如何解决这个问题来将提交推到连接到标记的分支本身，因为我需要在每一栋楼之后更新kustomize.yaml

就Git本身而言，分支名称和标记名称之间没有联系。

在Git级别上，任何名称--任何引用--都只是一个存储散列ID的名称。尤其是分支名称被限制为只存储提交散列ID，而标记名可以存储任何内部Git对象的散列ID。如果标记存储提交散列ID，则称为轻量级标记；如果存储标记对象的散列ID，则称为带注释的标记。然后，这个标记对象通常存储某些提交的散列ID。

可以使用git branch --points-at查找选择某些特定提交的分支名称，使用git tag --points-at查找选择某些特定提交的标记名称。有关详细信息，请参阅git branch和git tag文档。

请注意，您可以在这里为git tag提供提交散列ID，它仍然可以找到带注释的标记。从技术上讲，不管您是将标记对象命名为标记对象本身，还是命名为它的目标提交，它都会找到带注释的标记：

$ git rev-parse v2.3.0
42de6ed0c4c5c2a184b25ffeb4936af8226ccad1
$ git rev-parse v2.3.0^{commit}
9874fca7122563e28d699a911404fc49d2a24f1c
$ git tag --points-at 42de6ed0c4c5c2a184b25ffeb4936af8226ccad1
v2.3.0
$ git tag --points-at 9874fca7122563e28d699a911404fc49d2a24f1c
v2.3.0

但是，如果您试图找出哪个分支名称--从零到多--通过标记标识特定的提交，那么在运行git branch --points-at之前，您肯定需要先将标记名解析为提交散列ID。

不管怎么说，在我看来，你的总体计划似乎是毫无根据的。请记住，标记名的目的是始终标识一个特定的提交。原始散列ID也会这样做，但是标记名提供了原始散列ID没有的两个重要特性：

• 它至少具有人类可读性，并且可以具有语义，例如符号学部件。
• 它使您能够在不实际签署每个提交的情况下对提交进行签名。也就是说，您可以为标记提交提供GPG或其他数字签名，而不必在每次提交时使用GPG或其他数字签名(在大多数情况下，这比有用更有害:仅签署标记在某种意义上不太安全，但更有用，而有效安全性的关键是平衡痛苦级别和工作完成级别，以便人们实际使用它)。

同时，分支名称的目的是允许某些东西--人、计算机，有时两者兼而有之--找到一些特定但可以改变的提交。因此，我们为某个提交链的提示提交分配了一个分支名称，这是迄今为止我们最好的提交。然后，在改进内容时，我们向链添加新的提交，并移动分支名称。

对于正式的发布过程来说，这一切意味着你不会给一个发布候选人贴上标签，除非它会吸引更多的受众。您将使用分支名称标记此发布候选人。然后构建并测试它，如果它通过了内部测试，那么您可能会将它标记为发布候选版本，也许是在更新了某种构建定制之后。

换句话说，您将永远不会自定义标记的版本。您总是从一个分支定制--也许是一个特定的分支模式，但是是一个分支。然后，您可以标记自定义的版本，只要它已经准备好候选资格。如果它足够好，它将被授权为一个发布或"wide“(在本地组织之外的东西)被签名和验证(以便组织之外的人可以看到它是可信的，由谁来信任)。当然，不管是谁添加了签名，都应该确保信任链--在每一步进行的验证--都是有效的、不间断的。