Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Small issue with the tag feature #367

Closed
sconix opened this issue Feb 18, 2022 · 8 comments · Fixed by #374
Closed

Small issue with the tag feature #367

sconix opened this issue Feb 18, 2022 · 8 comments · Fixed by #374
Assignees
Labels
good first issue Good for newcomers status: pinned Should not be labeled as stale type: bug Verified problems that need to be worked on

Comments

@sconix
Copy link

sconix commented Feb 18, 2022

First of all really nice github action, everything in one action that one can need for updating git from Github action.

However we have a small issue with the tag updating feature. Our use case is to commit updated version in package.json file and generated changelog file when ever Github Release is made. So we naturally would also like to update the tag to point to the latest commit. However since this action first deleted the tag and then re-creates it Github will change the release back to draft state (deleting of the tag causes this).

So is there a reason why this action deletes the tag first and then creates it again? It would be much better if it would just force push the tag.

Of course we can always use another action to update the tag or set the release back to published state, but would be much nicer to be able to do everything in one step.

@sconix sconix added the status: pending More info is needed before deciding what to do label Feb 18, 2022
@EndBug
Copy link
Owner

EndBug commented Feb 22, 2022

To be honest, I don't remember what led to this decision, it was made when the tag input was used only for the tag name, and not all the arguments.
It's kind of janky, it would be better to remove this kind of behavior.

Anyway, in the meantime, you can just force update the tag by using --force in the tag input, and the action won't delete it.

@EndBug EndBug self-assigned this Feb 22, 2022
@EndBug EndBug added good first issue Good for newcomers status: pinned Should not be labeled as stale type: bug Verified problems that need to be worked on and removed status: pending More info is needed before deciding what to do labels Feb 22, 2022
@sconix
Copy link
Author

sconix commented Feb 22, 2022

This is what I have: tag: v1.3.2 --force

But it still deletes the tag first and then pushes a new one. The internal logs say:

hint: Updates were rejected because the tag already exists in the remote.

Tag push failed: deleting remote tag and re-pushing...

@EndBug
Copy link
Owner

EndBug commented Feb 23, 2022

Can you please add a link to the action run or, if the repo is private, a copy of your workflow step and your step log?

@sconix
Copy link
Author

sconix commented Feb 23, 2022

Sure, its private repo so hopefully here are all the required info:

 - name: Commit changes and update tag
        uses: EndBug/add-and-commit@v8
        with:
          add: CHANGELOG.md package*.json
          tag: ${{ github.event.release.tag_name }} --force
          message: Updated changelog and package version

Running in /home/runner/work/****
Add input parsed as single string, running 1 git add command.
> Using '**********' as author.
> Using "Updated changelog and package version" as commit message.
Internal logs
  > Staging files...
  > Adding files...
  > No files to remove.
  > Checking for uncommitted changes in the git working tree...
  > Found 1 changed files.
  ***
    raw: '',
    remote: 'https://github.com/*****',
    branches: [
      *** name: 'vue3-migration', tracking: 'origin/vue3-migration' ***
    ],
    tags: [
      *** name: 'v.2.0.1', tracking: 'v.2.0.1' ***,
      *** name: 'v1.0', tracking: 'v1.0' ***,
      *** name: 'v1.1', tracking: 'v1.1' ***,
      ... 61 more items
    ]
  ***
  > Not pulling from repo.
  > Creating commit...
  ***
    author: null,
    branch: 'master',
    commit: 'c55a8a5',
    summary: *** changes: 1, insertions: 2, deletions: 2 ***
  ***
  
  > Tagging commit...
  
  Updated tag 'v1.3.2' (was 81be4eb)
  
  Updated tag 'v1.3.2' (was 81be4eb)
  
  > Pushing commit to repo...
  
  ***
    pushed: [],
    update: ***
      head: *** local: 'refs/heads/master', remote: 'refs/heads/master' ***,
      hash: *** from: '81be4eb', to: 'c55a8a5' ***
    ***,
    repo: 'https://github.com/********',
    ref: *** local: 'refs/remotes/origin/master' ***,
    remoteMessages: RemoteMessageSummary *** all: [] ***
  ***
  > Pushing tags to repo...
  GitError: Pushing to https://github.com/********
  error: failed to push some refs to 'https://github.com/*******'
  hint: Updates were rejected because the tag already exists in the remote.
  
      at GitExecutorChain.onFatalException (/home/runner/work/_actions/EndBug/add-and-commit/v8/lib/index.js:7:157899)
      at GitExecutorChain.<anonymous> (/home/runner/work/_actions/EndBug/add-and-commit/v8/lib/index.js:7:157763)
      at Generator.throw (<anonymous>)
      at rejected (/home/runner/work/_actions/EndBug/add-and-commit/v8/lib/index.js:7:156781)
      at processTicksAndRejections (internal/process/task_queues.js:93:5) ***
    task: ***
      commands: [ 'push', 'origin', '--tags', '--verbose', '--porcelain' ],
      format: 'utf-8',
      parser: [Function: parsePushResult]
    ***
  ***
  > Tag push failed: deleting remote tag and re-pushing...
  ***
    pushed: [],
    repo: 'https://github.com/********',
    remoteMessages: RemoteMessageSummary *** all: [] ***
  ***
  ***
    pushed: [
      ***
        deleted: false,
        tag: true,
        branch: false,
        new: false,
        alreadyUpdated: true,
        local: 'refs/tags/v1.1.0',
        remote: 'refs/tags/v1.1.0'
      ***,
      ***
        deleted: false,
        tag: true,
        branch: false,
        new: false,
        alreadyUpdated: true,
        local: 'refs/tags/v1.2.0',
        remote: 'refs/tags/v1.2.0'
      ***,
      ***
        deleted: false,
        tag: true,
        branch: false,
        new: false,
        alreadyUpdated: true,
        local: 'refs/tags/v1.3.0',
        remote: 'refs/tags/v1.3.0'
      ***,
      ***
        deleted: false,
        tag: true,
        branch: false,
        new: false,
        alreadyUpdated: true,
        local: 'refs/tags/v1.3.1',
        remote: 'refs/tags/v1.3.1'
      ***,
      ***
        deleted: false,
        tag: true,
        branch: false,
        new: true,
        alreadyUpdated: false,
        local: 'refs/tags/v1.3.2',
        remote: 'refs/tags/v1.3.2'
      ***
    ],
    repo: 'https://*******',
    remoteMessages: RemoteMessageSummary *** all: [] ***
  ***
> Task completed.
Outputs
  committed: true
  commit_long_sha: c55a8a5ca06974aa8d16d340be9e96397e277545
  commit_sha: c55a8a5
  pushed: true
  tagged: true

@EndBug
Copy link
Owner

EndBug commented Feb 23, 2022

Oooh I get it: the thing is that the tag input actually works as intended, but it's when I'm pushing the tag that the --force flag is needed, but as of now there's no way to set it!
I'll add a new option to change the arguments of the tags push, as well as remove the janky delete and recreate behavior 👍🏻

@sconix
Copy link
Author

sconix commented Feb 23, 2022

Yes, I was actually kinda expecting that it would use the input explicitly for the push and not for the creation of the tag i.e. something on the lines of git push origin < tag > --force.

Thank you for looking into improving the tagging flow!

@EndBug
Copy link
Owner

EndBug commented Mar 11, 2022

@all-contributors please add @sconix for their idea

@allcontributors
Copy link
Contributor

@EndBug

I've put up a pull request to add @sconix! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers status: pinned Should not be labeled as stale type: bug Verified problems that need to be worked on
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants