Can’t figure why tags action does not fire

Bug Report

I’ve set up the integration to build docker images:

perftools/xhgui#428

I’ve read the readme, that needs to use org token:

perftools/xhgui#431

but still, the events for git push don’t fire:

https://github.com/perftools/xhgui/actions/workflows/docker.yml

it should build on pushed tags *.*.*, for example, 0.19.0:

https://github.com/perftools/xhgui/blob/0.19.0/.github/workflows/docker.yml#L12-L13

This is re-post of the forum post, since seems this project maintainers do not follow forums:

https://discourse.laminas.dev/t/support-automatic-releases-cant-figure-why-tags-action-does-not-fire/2586

In perftools/xhgui#431, the workflow is not designed to act on tags, only on milestone closed 🤔

@Ocramius but workflows/release-on-milestone-closed.yml creates git tag, pushes it. how to make github to invoke "on: tags" workflows?

https://github.com/perftools/xhgui/blob/de576f400c6c2fff0568c468da7357debccbb353/.github/workflows/docker.yml#L13

or you have some other ideas on how to make docker image when a release is made? perhaps document it?

Wait, so https://github.com/perftools/xhgui/blob/de576f400c6c2fff0568c468da7357debccbb353/.github/workflows/docker.yml#L13 is not triggered when the tag is created by laminas/automatic-releases? That could be because the tag is generated with a GITHUB_TOKEN, rather than an organisation admin token (bots don't lead to triggers)

But I changed to use org token (noted in bug report body):

perftools/xhgui#431

And if you check the tag, it's created by user, rather github-actions:

https://github.com/perftools/xhgui/releases/tag/0.19.0

Don't really know why it didn't trigger anything: I suggest creating a fork and trying out stuff there, with new tags 🤔

@glensc hey,

In the docker.yml trigger a build on "tags created"

# Controls when the action will run. 
on:
  # Triggers the workflow on push or pull request events but only for the main branch
  create:
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    if: ${{ startsWith(github.ref, 'refs/tags/v') }}
    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      # Runs a command
      - name: Run a build

To change the Author of the Tags, you have to set the secrets for the git author Name & Email.

          "GIT_AUTHOR_NAME": ${{ secrets.GIT_AUTHOR_NAME }}
          "GIT_AUTHOR_EMAIL": ${{ secrets.GIT_AUTHOR_EMAIL }}

ORGANIZATION_ADMIN_TOKEN & GITHUB_TOKEN are only used to interact with GitHub (query pr/issues |crud: branch, milestone, release), and not used to set git author.

hope that helps.

@ghostwriter are you saying io should switch from "on: push" to "on: create"?

https://github.com/perftools/xhgui/blob/829febcd7853646a8741baa24e8dd7919dc66f3c/.github/workflows/docker.yml#L8-L13

I've read the documentation and don't understand why one is better than the other:

also, your example is confusing, it says things that are not described there (what main branch?, why I need to filter tags with "if"). can you point to the origin of that workflow, as I think you redacted it too much and I can inspect runs of such workflow.

also, changing GIT_AUTHOR_EMAIL and GIT_AUTHOR_EMAIL does not change origin of the tag push events, it only changes metadata. the tag will be still be created with ORGANIZATION_ADMIN_TOKEN

and from UI it's already visible, the tags are not created with GITHUB_TOKEN=github-actions, but user token (look at the screenshot):

#175 (comment)

also: can you be distinct, that you know how to fix, or you guess how to fix?

Ok, after some testing, I've come to the conclusion that "on: push" and "on: create" difference is that "on: create" is fired only once. so it's suitable for tags run (tags are created once), but not suitable for branches.

NOTE: this is not a solution to the problem, just an observation about the "on: create" event.

I've changed GIT_AUTHOR_NAME/GIT_AUTHOR_EMAIL:

https://github.com/perftools/xhgui/pull/441/files

But it has no effect, the tag is still authored with my personal credentials:

https://github.com/perftools/xhgui/releases/tag/0.19.1

The tag author comes from where? gpg key?

➜ git show 0.19.1|head -n 20
tag 0.19.1
Tagger: Elan Ruusamäe <glen@pld-linux.org>
Date:   Sun Jan 16 12:38:01 2022 +0000

### Release Notes for [0.19.1](https://github.com/perftools/xhgui/milestone/19)

0.19.x bugfix release (patch)

### 0.19.1

- Total issues resolved: **0**
- Total pull requests resolved: **4**
- Total contributors: **2**

 - [442: Cleanup:  Remove adding ext-phar for build in Dockerfile](https://github.com/perftools/xhgui/pull/442) thanks to @glensc
 - [441: Set GIT&#95;AUTHOR&#95;NAME/GIT&#95;AUTHOR&#95;EMAIL via env rather secrets](https://github.com/perftools/xhgui/pull/441) thanks to @glensc
 - [438: Feature: Add driver name to PdoRepository](https://github.com/perftools/xhgui/pull/438) thanks to @glensc
 - [436: Implement pdo: getForUrl(), getPercentileForUrl(), getAll()](https://github.com/perftools/xhgui/pull/436) thanks to @fengqi
-----BEGIN PGP SIGNATURE-----

so what for the GIT_AUTHOR_NAME/GIT_AUTHOR_EMAIL are used if not tag creation?

@Ocramius can you add some debug mode to this workflow so could pin down what is happening based on commands executed and their environment? if there's any debug mode, it's not documented in README.md

I think adding -vvv is all we can do right now 🤔

tag author comes from where? gpg key?

we use --local-user: specifies a user id to use for signing.
https://github.com/laminas/automatic-releases/blob/1.14.x/src/Git/CreateTagViaConsole.php#L27

My example workflow regarding docker.yml was to show you how to setup a "Listener" to; Trigger the workflow on create request events but only for tags.

This ( https://github.com/perftools/xhgui/releases/tag/0.19.0 ) is not the "tag". This is the "Github Release Notes", it contains the contents of the CHANGELOG.md file. (It is created using the ORGANIZATION_ADMIN_TOKEN / GITHUB_TOKEN )

There's more broken that things don't fire. For example the merge-up pull request:

perftools/xhgui#444

it doesn't run the required workflows (configured in project settings), as those required workflows are "on: pull_requests" but apparently such event is not fired, only "push" event is fired (so that docker workflow runs).

which itself is odd, because docker image is not built on push+tags (which I need), but is fired with push+branch., major wtf .

tag author comes from where? gpg key?

we use --local-user: specifies a user id to use for signing. 1.14.x/src/Git/CreateTagViaConsole.php#L27

@ghostwriter so my guess was right, the email/name comes from gpg key, not GIT_AUTHOR_NAME/GIT_AUTHOR_EMAIL, and the documentation is incorrect?

@glensc I'm not sure.

I believe that may be the case, but only if --local-user overwrites git config user.*.

automatic-releases/src/Git/CreateTagViaConsole.php

Line 27 in 41da249

    
           Shell\execute('git', ['tag', $tagName, '-F', $tagFileName, '--cleanup=whitespace', '--local-user=' . $keyId->id()], $repositoryDirectory);

automatic-releases/src/Git/FetchAndSetCurrentUserByReplacingCurrentOriginRemote.php

Lines 31 to 32 in 41da249

    
           Shell\execute('git', ['config', 'user.email', $this->variables->gitAuthorEmail()], $repositoryRootDirectory); 
        
           Shell\execute('git', ['config', 'user.name', $this->variables->gitAuthorName()], $repositoryRootDirectory);

@ghostwriter in the last tag created by this workflow, the env variables are not used, because git show tagname shows my email not bot email:

#175 (comment)

my local test proves otherwise:

175-git-tag-author (master) ➜ git config user.name "XHGui Release Bot"
175-git-tag-author (master) ➜ git config user.email "xhgui-release-bot@github.com"
175-git-tag-author (master) ➜ git tag -s v1 -m test1 -u glen@pld-linux.org
175-git-tag-author (master) ➜ git show v1|head -n20
tag v1
Tagger: XHGui Release Bot <xhgui-release-bot@github.com>
Date:   Sun Jan 16 16:25:04 2022 +0200

test1
-----BEGIN PGP SIGNATURE-----

so. why things don't work for me with this workflow?

I think adding -vvv is all we can do right now 🤔

SHELL_VERBOSITY=3 is already set:

https://github.com/perftools/xhgui/blob/829febcd7853646a8741baa24e8dd7919dc66f3c/.github/workflows/release-on-milestone-closed.yml#L15-L17

@glensc you don't have an actual bot account (Github User), so when you supply a ORGANIZATION_ADMIN_TOKEN / GITHUB_TOKEN, that token is associated with your account.

Which is might be why all of the published/released tags are attributed to your account.

@ghostwriter this is pretty messy considering multiple topics at hand.

This issue (#175) is about that workflow doesn't fire. Currently, it's claimed that it doesn't fire is because tag is created with GITHUB_TOKEN.
1.. Proof that tag is created with my email is an indication that ORGANIZATION_ADMIN_TOKEN was used to create tag, not GITHUB_TOKEN.
(side topic) If GIT_AUTHOR_NAME/GIT_AUTHOR_EMAIL worked, the git tag would have been created with them, but my email is used.

please pay attention that token doesn't matter absolutely at all when git command is used to create tag. and the code you linked used git command not github api to create git tag.

so, I counter claim: git tag is created with ORGANIZATION_ADMIN_TOKEN and "on: push" still doesn't fire.

also worth understanding that technically git tag is created with git command (as you pointed to source), but tag is pushed with token. probably https protocol auth uses the same token.

so without debugging in code, it's impossible to tell externally what token was used to push the changes. or knowing the code. but I'm assuming git push is used over https URL to publish git tag.

@ghostwriter also you need to understand that GIT_AUTHOR_NAME/GIT_AUTHOR_EMAIL can be anything - these do not point to any account (bot or not). the git show I used, is metadata stored in git repository. see my example again. there is no github involved in that example. only git.

Related to verbosity, please check #76

Tag - a pointer to a specific commit.

Release - created from an existing tag and exposes release notes and links to download the software or source code from GitHub. (github.com/vendor/project/releases/tag/0.1.0)

https://stackoverflow.com/a/18512221
https://docs.github.com/en/rest/reference/releases

eg.
https://github.com/perftools/xhgui/tags
https://github.com/perftools/xhgui/releases

please pay attention that token doesn't matter absolutely at all when git command is used to create tag. and the code you linked used git command not GitHub api to create git tag.

you are correct, "git command is used to create tag".

when i said:

…you don't have an actual bot account (Github User), so when you supply a ORGANIZATION_ADMIN_TOKEN / GITHUB_TOKEN, that token is associated with your account.

I was talking about the "Github Release", which requires an authenticated user.

automatic-releases/src/Github/Api/V3/CreateReleaseThroughApiCall.php

Lines 44 to 51 in 41da249

    
           $request = $this->messageFactory 
        
               ->createRequest( 
        
                   'POST', 
        
                   self::API_ROOT . 'repos/' . $repository->owner() . '/' . $repository->name() . '/releases' 
        
               ) 
        
               ->withAddedHeader('Content-Type', 'application/json') 
        
               ->withAddedHeader('User-Agent', 'Ocramius\'s minimal API V3 client') 
        
               ->withAddedHeader('Authorization', 'token ' . $this->apiToken);

My understanding is:

2 workflows [AutoRelease.yml, DockerBuild.yml].
3 issues.

AutoRelease: `git tag` author info is ambiguous. (git, gpg)

automatic-releases/src/Git/FetchAndSetCurrentUserByReplacingCurrentOriginRemote.php

Lines 31 to 32 in 41da249

    
           Shell\execute('git', ['config', 'user.email', $this->variables->gitAuthorEmail()], $repositoryRootDirectory); 
        
           Shell\execute('git', ['config', 'user.name', $this->variables->gitAuthorName()], $repositoryRootDirectory);

we can add: user.signingkey and commit.gpgsign

 // FetchAndSetCurrentUserByReplacingCurrentOriginRemote.php
 Shell\execute('git', ['config', 'user.signingkey', $this->variables->signingkey()], $repositoryRootDirectory); 
 Shell\execute('git', ['config', 'commit.gpgsign', 'true'], $repositoryRootDirectory);

remove '--local-user=' . $keyId->id()

automatic-releases/src/Git/CreateTagViaConsole.php

Line 27 in 41da249

    
           Shell\execute('git', ['tag', $tagName, '-F', $tagFileName, '--cleanup=whitespace', '--local-user=' . $keyId->id()], $repositoryDirectory);

AutoRelease: `GitHub release` author is ambiguous. (token)

You have to provide an ORGANIZATION_ADMIN_TOKEN (with a full repo scope), which is a GitHub token with administrative rights over your organization (or regular user project, for non-organization projects), issued by a user that has administrative rights over your project (that's you, if it is your own non-organization repository).

The ORGANIZATION_ADMIN_TOKEN and or GITHUB_TOKEN you provide is associated to the user that created it.

This token is used to authenticate and attribute GitHub related actions.

CRUD Branches
CRUD Issues
CRUD Milestones
CRUD & Merge PRs
CRUD Releases

If you have plans to use a Bot, to attribute GitHub related actions (eg. Release "bot-user released 0.1.0"), you should create a dedicated GitHub user account for the bot.

DockerBuild: not triggered via `git tag` event.

I recommend using the on: create event for this.

on:
  # run on all PRs
  pull_request:
  # run on push if branch name match pattern
  push:
    branches:
      - "*.*.x"
    tags:
      - "*.*.*"
  # run on create if branch or tag name match pattern
  create:
    branches:
      - "*.*.x"
    tags:
      - "*.*.*"

we can try git push --follow-tags origin {tag} here.

automatic-releases/src/Git/PushViaConsole.php

Lines 25 to 27 in 41da249

    
           Shell\execute('git', ['branch', $localTemporaryBranch, $symbol], $repositoryDirectory); 
        
           Shell\execute('git', ['push', 'origin', $localTemporaryBranch . ':' . $alias], $repositoryDirectory); 
        
           Shell\execute('git', ['branch', '-D', $localTemporaryBranch], $repositoryDirectory);

Also https://github.com/actions/checkout mentions.

The auth token is persisted in the local git config. This enables your scripts to run authenticated git commands. The token is removed during post-job cleanup. Set persist-credentials: false to opt-out.

I recommend using the on: create event for this.

I asked you, have you tested this, or you are just guessing this will work? did not notice you replied. can you answer now? and why would "on: create" work and "on: push" will not? do you have workflow where this works?

ps: I know what is git tag, git lightweight tag, git annotated tag and git signed tag and github releases. i was just pointing to the tag so you can see of what git object I was talking of. and what is the GIT_AUTHOR_EMAIL stored on the object. github UI no longer allows to link to just tag if release also exists.

If you have plans to use a Bot, to attribute GitHub related actions (eg. Release "bot-user released 0.1.0"), you should create a dedicated GitHub user account for the bot.

I wanted to change GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL that are attached to the git tag. Currently, the env variables in CI do not have the intended effect.

I asked you, have you tested this, or you are just guessing this will work? did not notice you replied. can you answer now? and why would "on: create" work and "on: push" will not? do you have workflow where this works?

Yes, It works. I'm using it just fine.

You will find a few repos that use this method linked to this issue, including the example workflow i shared earlier. actions/runner#1007

ps: I know what is git tag, git lightweight tag, git annotated tag and git signed tag and github releases. i was just pointing to the tag so you can see of what git object I was talking of. and what is the GIT_AUTHOR_EMAIL stored on the object. github UI no longer allows to link to just tag if release also exists.

Great! we're on the same page.

I wanted to change GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL that are attached to the git tag. Currently, the env variables in CI do not have the intended effect.

Correct.

The difference between push and create event is the valuse assigned to these two variables: GITHUB_SHA & GITHUB_REF

push

GITHUB_SHA = Commit pushed, unless deleting a branch (when it's the default branch)
GITHUB_REF = Updated ref

create

GITHUB_SHA = Last commit on the created branch or tag
GITHUB_REF = Branch or tag created

Note:

An event will not be created when you create more than three tags at once, with both push and create.

Changing to "on: create" had no effect!

Okay. the docker build on tag creation is now fired after this PR:

perftools/xhgui#465

but merge-up test jobs are still not fired:

#175 (comment)

example:

Hey @glensc,

Reason: "This branch is out-of-date with the base branch"

If I'm not mistaken, your current default branch 0.21.x has a "Require status checks to pass before merging" and "Require branches to be up to date before merging" enabled with an invalid branch protection rule.

It expects 3 workflows with the name "PHP 7.2", "PHP 7.3", and "PHP 7.4" to run, but they are not in your repo.

Please remove the invalid/outdated status check in the protected branch setting of the repository settings.

For example:

I had set the two checks "Build" and "Trigger Azure pipeline run" as " Required". But the job "Trigger Azure pipeline run" was not actually executed because I had removed/renamed it from the workflow, it stuck here.

So I go to update the branch rules to disable "Trigger Azure pipeline run".

Then reopen/refresh the page of the PR, all checks were passed, and I can merge the PR.

Hope that helps.

It expects 3 workflows with the name "PHP 7.2", "PHP 7.3", and "PHP 7.4" to run, but they are not in your repo.

this incorrect. the same workflow works fine if I am the one initiating the push:

perftools/xhgui#467

and this is what workflows autocomplete shows if I try to change:

I've removed "Require branches to be up to date before merging". but I'm pretty sure that is not the reason why those jobs were not executed. why two other jobs were executed? Publish Docker image for example. Does not make sense.

But changing the state won't re-run the actions.

so I disabled actions at all, and re-enabled. now both can be merged but the tests were not run at all, like they don't exist.

But your message made me think. maybe the problem is that different workflows have jobs with the same name:

    name: PHP ${{ matrix.php }}

@glensc

I've removed "Require branches to be up to date before merging". but I'm pretty sure that is not the reason why those jobs were not executed. why two other jobs were executed? Publish Docker image for example. Does not make sense.

Yes, it does make sense.

The tests are triggered by the pull_request event whereas the other workflows are triggered by the push event.

Workflows will not run on the pull_request event if the pull request has a merge conflict. The merge conflict must be resolved first.

Conversely, workflows with the pull_request_target event will run even if the pull request has a merge conflict. Before using the pull_request_target trigger, you should be aware of the security risks. For more information, see pull_request_target.

--

But changing the state won't re-run the actions.

closing and reopening the PR should re-trigger the event.

By default, a workflow only runs when a pull_request event's activity type is opened, synchronize, or reopened.

The merge up CI seems to have passed now:

perftools/xhgui#472

There were no changes to CI config in git repo, but project settings was changed to remove "require branch to be up to date"

So this could not have been the reason of it being broken before:

It expects 3 workflows with the name "PHP 7.2", "PHP 7.3", and "PHP 7.4" to run, but they are not in your repo.

Since both problems were solved:

Docker image build doesn't fire
Merge up Jobs don't fire

I'm going to close now. Thanks for the support.

	Shell\execute('git', ['config', 'user.email', $this->variables->gitAuthorEmail()], $repositoryRootDirectory);
	Shell\execute('git', ['config', 'user.name', $this->variables->gitAuthorName()], $repositoryRootDirectory);

	$request = $this->messageFactory
	->createRequest(
	'POST',
	self::API_ROOT . 'repos/' . $repository->owner() . '/' . $repository->name() . '/releases'
	)
	->withAddedHeader('Content-Type', 'application/json')
	->withAddedHeader('User-Agent', 'Ocramius\'s minimal API V3 client')
	->withAddedHeader('Authorization', 'token ' . $this->apiToken);

	Shell\execute('git', ['branch', $localTemporaryBranch, $symbol], $repositoryDirectory);
	Shell\execute('git', ['push', 'origin', $localTemporaryBranch . ':' . $alias], $repositoryDirectory);
	Shell\execute('git', ['branch', '-D', $localTemporaryBranch], $repositoryDirectory);