Giter Club home page Giter Club logo

action-create-tag's People

Contributors

dependabot[bot] avatar dym-ok avatar intrepidd avatar octocat avatar renovate-bot avatar renovate[bot] avatar rickstaa avatar tiagofragoso avatar varya avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

action-create-tag's Issues

`tag_exists_error: false` still errors if tag already exists on remote.

Describe the bug
Docs state the argument:

tag_exists_error: false

Prevents the action from failing if the tag already exists. But it appears the action still errors and fails due to the given tag existing even with this parameter provided.

To Reproduce
Steps to reproduce the behavior:

  • Create tag
  • configure action with tag_exists_error: false
  • run action on existing tag
  • see error

Expected behavior
Action should not error if tag already exists when tag_exists_error: false is present.

Screenshots
image

image

Additional context
Add any other context about the problem here.

Unable to tag non main branch

I am unable to tag when running the action from branches other then main/master.

remote: fatal error in commit_refs        
To https://github.com/XXXXXX
 ! [remote rejected]       11.2.4.1221 -> 11.2.4.1221 (failure)
error: failed to push some refs to 'https://github.com/XXXXXX'

Works fine when runs on master, any ideas ?

[UPSTREAM_BUG] tags not being feteched in in checkout v4

Bug Description:

A bug has been identified in version 4 of the actions/checkout GitHub Action, where the fetch-tags argument set to true fails to fetch tags. This issue is documented on GitHub.

Steps to Reproduce:

  1. Create a new repository.
  2. Add the following action file in the .github/workflows folder:
name: Create/update tag
on:
  workflow_dispatch:
jobs:
  create-tag:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-tags: true
      - uses: rickstaa/action-create-tag@v1
        id: "tag_create"
        with:
          tag: "latest"
          tag_exists_error: false
          message: "Latest release"

      # Print result using the env variable.
      -  run: |
          echo "Tag already present: ${{ env.TAG_EXISTS }}"

      # Print result using the action output.
      - run: |
          echo "Tag already present: ${{ steps.tag_create.outputs.tag_exists }}"
  1. Push the latest tag to the branch to ensure its existence.
  2. Run the action using the GitHub Action interface.
  3. Observe that the tag is not found, and a hint: Updates were rejected because the tag already exists in the remote. error is thrown.

Expected Behavior:

As per the actions/checkout documentation, the provided action recipe should fetch tags, and the tag should be recognized as already present.

Solution:

As a temporary solution, update the README to instruct users to use the fetch-depth: 0 argument to fetch all tags until GitHub issue #1471 is resolved. Once fixed, the fetch-tags: true argument can be used again.

Ref to tag should be sha of workflow, not commit_sha

Describe the bug
If a workflow is triggered from one branch, and then actions/checkout is invoked to check out a different branch, action-create-tag attempts to tag the wrong commit, generating a "fatal: bad object type" error.

To Reproduce
Steps to reproduce the behavior:

  1. Create an action that does a checkout from a branch different from the commit that triggered the workflow.
  2. In the yaml, call actions/checkout followed by action-create-tag.
  3. An error will result due to a mismatch between the expected commit of the workflow and commit_sha, which still reflects the triggering workflow commit.

Expected behavior
It's not clear to my why the GH folks think it's a good idea to leave commit_sha set to the triggering workflow. But when a checkout on a different branch is done, commit_sha is no longer accurate, and action_create_tag should be using as the default the commit sha of the checkout.

Workaround
The only workaround I've found is to add an extra step to get the workspace commit, and override the action default:

    - uses: actions/checkout@v4
      with:
        progress: false
        ref: ${{ inputs.build-branch }}

    - name: Get workspace sha
      run: |
        echo "WORKSPACE_SHA=$(/usr/bin/git log -1 --format='%H')" >> $GITHUB_ENV

    - name: Tag the commit with the version
      uses: rickstaa/action-create-tag@v1
      with:
        tag: ${{env.TAG}}
        commit_sha: ${{ env.WORKSPACE_SHA }}

Support for Windows and Mac

Is your feature request related to a problem? Please describe.

Running this on a Windows and Mac is not supported:
image

Describe the solution you'd like

Either support Windows and Mac or document on readme that this action only supports Linux.

Describe alternatives you've considered
The current alternative is to find another Github action to use ๐Ÿ˜‡

Add support for Git LFS

Is your feature request related to a problem? Please describe.
This action doesn't currently support Git LFS. Came across the following error when using this action in a repo with Git LFS:

This repository is configured for Git LFS but 'git-lfs' was not found on your path.

Describe the solution you'd like
Add Git LFS to the container.

Describe alternatives you've considered

Additional context

GITHUB_OUTPUT: parameter not set error

Hello, I am trying to use your action in my workflow and I am getting the following error when running it:

/entrypoint.sh: line 29: GITHUB_OUTPUT: parameter not set

Am I the only one, hence am I doing something wrong? I am using the latest version 1.6.1 from the action btw.

This is how my call looks like:

- name: Create git tag
  uses: rickstaa/[email protected]
  with:
     tag: "${{ inputs.new_release_version }}"
     message: "Release ${{ inputs.new_release_version}}"

fatal: bad object type. issue in a reusable workflow

Describe the bug
It seems there is an error when creating a new tag from a reusable workflow. If the tag that not exists, then it fails, but if the tag already exists, so it works as expected.

To Reproduce

#version.yml
name: "Versioning Reusable"

on:
  workflow_call:

jobs:
  versioning_generator:
    runs-on: ubuntu-22.04
    name: Sem Version Generator

    steps:
      # clones the current repository
      - name: Checkout current repository
        uses: actions/checkout@v3
        with:
          ref: ${{ github.head_ref }} # checkout the correct branch name
          fetch-depth: 0 # fetch the whole repo history

      # release tag version on repository
      - name: Tag Release
        uses: rickstaa/[email protected]
        with:
          tag: "api_fronten2/v0.1.2"
          message: "Releasing version myapp/v0.1.0"
# test_version.yml
name: Test Versioning

on:
  pull_request:
    branches:
      - main
    types: [opened, reopened, synchronize]

jobs:

  versioning:
    name: VER
    uses: ./.github/workflows/version.yml

Expected behavior
release a tag from a reusable workflow

Additional context

Run rickstaa/[email protected]
  with:
    tag: api_fronten[2](https://github.com/dtcMLOps/test-github-action/actions/runs/3707243389/jobs/6283418934#step:6:2)/v0.1.2
    message: Releasing version api_fronten2/v0.1.2
    github_token: ***
    force_push_tag: false
    no_verify_tag: false
/usr/bin/docker run --name d0a550951962426eb[3](https://github.com/dtcMLOps/test-github-action/actions/runs/3707243389/jobs/6283418934#step:6:3)7077[4](https://github.com/dtcMLOps/test-github-action/actions/runs/3707243389/jobs/6283418934#step:6:4)e2932cb[5](https://github.com/dtcMLOps/test-github-action/actions/runs/3707243389/jobs/6283418934#step:6:5)[6](https://github.com/dtcMLOps/test-github-action/actions/runs/3707243389/jobs/6283418934#step:6:6)_bfc[7](https://github.com/dtcMLOps/test-github-action/actions/runs/3707243389/jobs/6283418934#step:6:7)[8](https://github.com/dtcMLOps/test-github-action/actions/runs/3707243389/jobs/6283418934#step:6:9)f --label 2[9](https://github.com/dtcMLOps/test-github-action/actions/runs/3707243389/jobs/6283418934#step:6:10)0506 --workdir /github/workspace --rm -e "INPUT_TAG" -e "INPUT_MESSAGE" -e "INPUT_GITHUB_TOKEN" -e "INPUT_COMMIT_SHA" -e "INPUT_FORCE_PUSH_TAG" -e "INPUT_NO_VERIFY_TAG" -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e "GITHUB_RUN_ATTEMPT" -e "GITHUB_ACTOR" -e "GITHUB_TRIGGERING_ACTOR" -e "GITHUB_WORKFLOW" -e "GITHUB_HEAD_REF" -e "GITHUB_BASE_REF" -e "GITHUB_EVENT_NAME" -e "GITHUB_SERVER_URL" -e "GITHUB_API_URL" -e "GITHUB_GRAPHQL_URL" -e "GITHUB_REF_NAME" -e "GITHUB_REF_PROTECTED" -e "GITHUB_REF_TYPE" -e "GITHUB_WORKSPACE" -e "GITHUB_ACTION" -e "GITHUB_EVENT_PATH" -e "GITHUB_ACTION_REPOSITORY" -e "GITHUB_ACTION_REF" -e "GITHUB_PATH" -e "GITHUB_ENV" -e "GITHUB_STEP_SUMMARY" -e "GITHUB_STATE" -e "GITHUB_OUTPUT" -e "RUNNER_OS" -e "RUNNER_ARCH" -e "RUNNER_NAME" -e "RUNNER_TOOL_CACHE" -e "RUNNER_TEMP" -e "RUNNER_WORKSPACE" -e "ACTIONS_RUNTIME_URL" -e "ACTIONS_RUNTIME_TOKEN" -e "ACTIONS_CACHE_URL" -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/test-github-action/test-github-action":"/github/workspace" 290506:d0a550951962426eb370774e2932cb56
fatal: bad object type.
[action-create-tag] Create tag 'api_fronten2/v0.1.2'.

Input to indicate if the tag exists skip creation process

Is your feature request related to a problem? Please describe.
We have 2 options regarding existing tags. Overwrite or raise an error if the tag exists

Describe the solution you'd like
An input to validate if the tag exists skips the creation process and proceeds to the next job in the workflow. This can be used to avoid the dangerous option of overwriting a tag and still we will have a successful execution on the job.

Describe alternatives you've considered
Move the create tag job at the end of my workflow (is not the perfect solution)

Additional context
Add any other context or screenshots about the feature request here.

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

dockerfile
Dockerfile
  • alpine 3.18
github-actions
.github/workflows/code_quality.yml
  • actions/checkout v4
  • haya14busa/action-cond v1
  • reviewdog/action-shellcheck v1
  • actions/checkout v4
  • haya14busa/action-cond v1
  • reviewdog/action-hadolint v1
  • actions/checkout v4
  • reviewdog/action-misspell v1
  • actions/checkout v4
  • reviewdog/action-alex v1
.github/workflows/dockerimage.yml
  • actions/checkout v4
.github/workflows/release.yml
  • actions/checkout v4
  • haya14busa/action-bumpr v1
  • haya14busa/action-update-semver v1
  • haya14busa/action-cond v1
  • actions/create-release v1
  • actions/checkout v4
  • haya14busa/action-bumpr v1

  • Check this box to trigger a request for Renovate to run again on this repository

Support for Mac

Describe the bug
The bug is not specified that this action only runs on linux

Failed to resolve '' as a valid ref.

When using this action in a push event:

name: Auto Tag

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
      with:
        fetch-depth: '0'
    - name: "Tag minor version"
      uses: rickstaa/action-create-tag@v1
      with:
        tag: "v0.7"
        message: "Test message"
        force_push_tag: true

Got error:

[action-create-tag] Create tag 'v0.7'.
fatal: Failed to resolve '' as a valid ref.

Resolved by adding optional input commit_sha:

    - name: "Tag minor version"
      uses: rickstaa/action-create-tag@v1
      with:
        tag: "v0.7"
        message: "Test message"
        force_push_tag: true
        commit_sha: ${{ github.sha }}

Expect that the optional commit_sha variable is not specified and use the current commit automatically.

cannot lock ref 'refs/tags': Filename too long

Im getting the following error:

[action-create-tag] Create tag 'v***.***'.
fatal: cannot lock ref 'refs/tags/v***.***': Unable to create '/github/workspace/.git/refs/tags/v***.***.lock': Filename too long

The Filename too long part is very weird, since my tags are very short (5 characters) and the path in the message doesn't seem long at all.

Could there be something else that is causing this? For example, my master branch is protected to not accept push, only pull request. Does the tag creation require a push for example?

Sining with GPG is failing with error gpg: error reading key: No public key

Describe the bug
Sining with GPG is failing with error gpg: error reading key: No public key

To Reproduce
Steps to reproduce the behavior:
I Have following Github Action
`name: Nightly tag
on:
pull_request:
branches: ["main"]

jobs:
tag:
name: Tag
runs-on: ubuntu-latest

steps:
  - name: Checkout branch "main"
    uses: actions/checkout@v4
    with:
      fetch-depth: 0 # fetch the whole repo history

  - name: Generate Git Tag
    id: generate_tag
    run: |
        MINOR_VERSION=${{ vars.AS_MINOR_VERSION }}
        MINOR_VERSION=$((MINOR_VERSION + 1))
        NEW_TAG="nightly-${{ vars.AS_MAJOR_VERSION }}.${{ vars.AS_MINOR_VERSION }}"
        echo "Generated new tag: $NEW_TAG"
        echo "NEW_TAG=$NEW_TAG" >> $GITHUB_ENV
        echo "MINOR_VERSION=$MINOR_VERSION" >> $GITHUB_ENV
  - name: Create tag
    uses: rickstaa/action-create-tag@v1
    id: "tag_create"
    with:
        tag: $NEW_TAG
        tag_exists_error: false
        message: "Github nightly release tag"
        gpg_private_key: ${{ secrets.GPG_PRIVATE_KEY }}
        gpg_passphrase: ${{ secrets.GPG_PASSPHRASE }}

  - name: Update nimor version veriable
    run: |
      gh variable set AS_MINOR_VERSION --body "$MINOR_VERSION"
      `

GPG Key Created from my local machine and uploaded to Github with passphrase

Getting following error on action
gpg: directory '/github/home/.gnupg' created [action-update-semver] Importing GPG key. gpg: /github/home/.gnupg/trustdb.gpg: trustdb created gpg: key <correct key id>: public key "<Correct name> <my correct email>" imported gpg: key <correct key id>: secret key imported gpg: Total number processed: 1 gpg: imported: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 [action-update-semver] Unlocking GPG key. gpg: error reading key: No public key gpg: error reading key: No public key [action-update-semver] Setup git user name, email, and signingkey. [action-create-tag] Create tag '$NEW_TAG'. Committer identity unknown *** Please tell me who you are. Run git config --global user.email "[email protected]" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: empty ident name (for <>) not allowed

Expected behavior
Tag should get created without error

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

"fatal: bad object type" error when trying to upsert a (sliding) tag based on another extant tag

I have multiple github repositories which employ the same github workflows. One such is a reusable workflow that's part of a simple, manually triggered action. The action accepts as input a tag name and a deployment environment target (dev, prod, etc.). This workflow has a simple job: upsert a (sliding) tag into the repository called deployed-to-[environment], the sha of which matches that of the named "source" tag.

Here's the workflow YML in full:

name: Tag Deployment

on:
  workflow_call:
    inputs:
      target:
        description: "Deployment Target ('dev', 'prod', ...)"
        type: string
        required: true
      ref:
        description: "Git ref to tag"
        type: string
        required: true

jobs:

  update-deployment-tag:
    name: Upsert Deployment Tag
    runs-on: ubuntu-latest
    steps:

      # https://github.com/actions/checkout
      - uses: actions/checkout@v3
        with:
          ref: "${{ inputs.ref }}"

      # https://github.com/rickstaa/action-create-tag
      - uses: rickstaa/action-create-tag@v1
        with:
          tag: "deployed-to-${{ inputs.target }}"
          message: "Version currently deployed to '${{ inputs.target }}' environment"
          force_push_tag: true

This same workflow behaves as expected on several repositories, but on one in particular, it fails with fatal: bad object type. And I cannot discern the cause of this failure (and thus what must be unique about this one repository).

The checkout step seems to work fine, but then the tag creation just sorta unceremoniously falls over. And this happens whether the to-be-created tag already exists or not.

2023-07-13T18:46:00.1984193Z ##[group]Determining the checkout info
2023-07-13T18:46:00.1985152Z [command]/usr/bin/git branch --list --remote origin/0.0.2.101
2023-07-13T18:46:00.2024745Z [command]/usr/bin/git tag --list 0.0.2.101
2023-07-13T18:46:00.2060032Z 0.0.2.101
2023-07-13T18:46:00.2083515Z ##[endgroup]
2023-07-13T18:46:00.2084065Z ##[group]Checking out the ref
2023-07-13T18:46:00.2084667Z [command]/usr/bin/git checkout --progress --force refs/tags/0.0.2.101
2023-07-13T18:46:00.2426408Z Note: switching to 'refs/tags/0.0.2.101'.
2023-07-13T18:46:00.2447782Z 
2023-07-13T18:46:00.2448639Z You are in 'detached HEAD' state. You can look around, make experimental
2023-07-13T18:46:00.2450041Z changes and commit them, and you can discard any commits you make in this
2023-07-13T18:46:00.2450787Z state without impacting any branches by switching back to a branch.
2023-07-13T18:46:00.2451619Z 
2023-07-13T18:46:00.2452217Z If you want to create a new branch to retain commits you create, you may
2023-07-13T18:46:00.2453454Z do so (now or later) by using -c with the switch command. Example:
2023-07-13T18:46:00.2453863Z 
2023-07-13T18:46:00.2454729Z   git switch -c <new-branch-name>
2023-07-13T18:46:00.2455182Z 
2023-07-13T18:46:00.2456688Z Or undo this operation with:
2023-07-13T18:46:00.2457087Z 
2023-07-13T18:46:00.2457876Z   git switch -
2023-07-13T18:46:00.2458374Z 
2023-07-13T18:46:00.2459207Z Turn off this advice by setting config variable advice.detachedHead to false
2023-07-13T18:46:00.2459700Z 
2023-07-13T18:46:00.2460769Z HEAD is now at 56cf1f0 Some redacted thing
2023-07-13T18:46:00.2470208Z ##[endgroup]
2023-07-13T18:46:00.2486753Z [command]/usr/bin/git log -1 --format='%H'
2023-07-13T18:46:00.2517667Z '56cf1f0e31ff41f84a0357f3fa979ec165283d23'
2023-07-13T18:46:00.2882722Z ##[group]Run rickstaa/action-create-tag@v1
2023-07-13T18:46:00.2883090Z with:
2023-07-13T18:46:00.2883414Z   tag: deployed-to-prod
2023-07-13T18:46:00.2883786Z   message: Version currently deployed to 'prod' environment
2023-07-13T18:46:00.2884095Z   force_push_tag: true
2023-07-13T18:46:00.2884646Z   github_token: ***
2023-07-13T18:46:00.2885218Z   tag_exists_error: true
2023-07-13T18:46:00.2885521Z   no_verify_tag: false
2023-07-13T18:46:00.2885760Z ##[endgroup]
2023-07-13T18:46:00.3129732Z ##[command]/usr/bin/docker run --name c9a4a5fe520db488f4431590b5b84969aba6a8_424927 --label c9a4a5 --workdir /github/workspace --rm -e "INPUT_TAG" -e "INPUT_MESSAGE" -e "INPUT_FORCE_PUSH_TAG" -e "INPUT_GITHUB_TOKEN" -e "INPUT_COMMIT_SHA" -e "INPUT_TAG_EXISTS_ERROR" -e "INPUT_NO_VERIFY_TAG" -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e "GITHUB_REPOSITORY_OWNER_ID" -e "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e "GITHUB_RUN_ATTEMPT" -e "GITHUB_REPOSITORY_ID" -e "GITHUB_ACTOR_ID" -e "GITHUB_ACTOR" -e "GITHUB_TRIGGERING_ACTOR" -e "GITHUB_WORKFLOW" -e "GITHUB_HEAD_REF" -e "GITHUB_BASE_REF" -e "GITHUB_EVENT_NAME" -e "GITHUB_SERVER_URL" -e "GITHUB_API_URL" -e "GITHUB_GRAPHQL_URL" -e "GITHUB_REF_NAME" -e "GITHUB_REF_PROTECTED" -e "GITHUB_REF_TYPE" -e "GITHUB_WORKFLOW_REF" -e "GITHUB_WORKFLOW_SHA" -e "GITHUB_WORKSPACE" -e "GITHUB_ACTION" -e "GITHUB_EVENT_PATH" -e "GITHUB_ACTION_REPOSITORY" -e "GITHUB_ACTION_REF" -e "GITHUB_PATH" -e "GITHUB_ENV" -e "GITHUB_STEP_SUMMARY" -e "GITHUB_STATE" -e "GITHUB_OUTPUT" -e "RUNNER_OS" -e "RUNNER_ARCH" -e "RUNNER_NAME" -e "RUNNER_ENVIRONMENT" -e "RUNNER_TOOL_CACHE" -e "RUNNER_TEMP" -e "RUNNER_WORKSPACE" -e "ACTIONS_RUNTIME_URL" -e "ACTIONS_RUNTIME_TOKEN" -e "ACTIONS_CACHE_URL" -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/redacted/repository":"/github/workspace" c9a4a5:fe520db488f4431590b5b84969aba6a8
2023-07-13T18:46:00.6115484Z [action-create-tag] Create tag 'deployed-to-prod'.
2023-07-13T18:46:00.6124989Z fatal: bad object type.

And unlike the OP from issue #28, I don't know that removing the ref from my checkout action is an option here, nor does it seem to be required for several of my other repositories that do this exact same thing.

[UPSTREAM_BUG] Error: fatal: not in a git directory

This action has been workign flawlessly for months, thanks !

Since yesterday I now get the fatal: not in a git directory error when running the action. The action version has not changed so this may be an issue with github actions itself or something may have changed ?

Run rickstaa/action-create-tag@v1
  with:
    tag: latest_release
    force_push_tag: true
    commit_sha: xxxx
    github_token: ***
/usr/bin/docker run --name xxx --label xxx --workdir /github/workspace --rm -e INPUT_TAG -e INPUT_FORCE_PUSH_TAG -e INPUT_COMMIT_SHA -e INPUT_GITHUB_TOKEN -e INPUT_MESSAGE -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_RETENTION_DAYS -e GITHUB_RUN_ATTEMPT -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_SERVER_URL -e GITHUB_API_URL -e GITHUB_GRAPHQL_URL -e GITHUB_REF_NAME -e GITHUB_REF_PROTECTED -e GITHUB_REF_TYPE -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e GITHUB_ACTION_REPOSITORY -e GITHUB_ACTION_REF -e GITHUB_PATH -e GITHUB_ENV -e GITHUB_STEP_SUMMARY -e RUNNER_OS -e RUNNER_ARCH -e RUNNER_NAME -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/xxx":"/github/workspace" xxx:xxx
fatal: not in a git directory

Message by @rickstaa

Https://github.blog/2022-04-12-git-security-vulnerability-announced/ introduced the problem above. A official statement of the GitHub team about this problem can be found here.

I applied workaround #11, provided by @Intrepidd, to the main branch. This is also the suggested workaround in actions/checkout#766. This fix can be removed in the future when a patch has been applied to the action ecosystem (See actions/checkout#766). I will keep this issue open until an upstream fix has been applied.

Invalid username or password error when executed in different job than actions/checkout

Describe the bug

when rickstaa/action-create-tag@v1 is executed in an other job than the one where actions/checkout is executed I get this error

remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/elendil-software/name-of-the-repo.git/'

To Reproduce

Here is a workflow I used to reproduce the problem.
It create a tag in the same job than the checkout action, and another one in other job. The first tag is correctly created, but the second one produce the error.
The repository content is shared between jobs with an artifact.

name: 'Test Tag Workflow'

on:
  pull_request:
    branches: [ main ]
  workflow_dispatch:  

jobs:
  init:
    runs-on: ubuntu-latest
    
    steps:
    - name: Checkout
      uses: actions/checkout@v3
      with:
        fetch-depth: 0
        
    # This tag is correctly created
    - name: Create Tag
      uses: rickstaa/action-create-tag@v1
      with:
        tag: 3.0.0
        message: "3.0.0"
        github_token: ${{ secrets.GITHUB_TOKEN }}
        
    - name: Upload source directory
      uses: actions/upload-artifact@v3
      with:
        name: 1-after-clone
        path: ./ 
        
  tag:
    runs-on: ubuntu-latest
    needs: init
    steps:
    - name: Download source directory
      uses: actions/download-artifact@v3
      with:
        name: 1-after-clone
        
    # This call produce the error
    - name: Create Tag
      uses: rickstaa/action-create-tag@v1
      with:
        tag: 3.0.1
        message: "3.0.1"
        github_token: ${{ secrets.GITHUB_TOKEN }}

Expected behavior
Should work in both cases

Can I used PATs for the GITHUB_TOKEN to create protected tags

Describe the bug

Tag creation using this action fails for protected tags due to permission issues.

To Reproduce
Steps to reproduce the behavior:

  1. Create a tag protection rule
  2. Try to create this protected tag with this action while setting the github_token with a personal access token that has the required permissions.

Expected behavior
The tag would be created

Additional context
This is only half a bug report. First of all, I want to understand if this is supported at all.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.