What is the best way to push code + tags to github?

[Zaloog]

Hello,
thank you very much for pyscaffold. It helped me deploying my own first package.

I have a question though regarding what the best way to push the code + tags to the repo is.

git push && git push --tags 

Does 2 separate pushes and therefore 2 gh action triggers.

git push origin tag <TAG>

Is pushing the Tag, which is connected with the specific commit, but then the code in the repo is not up to date.

Could you elaborate on the best way to push teh code and the tags?
Thank you

[abravalheri]

I usually use:

git push origin <tag> <branch> ...

You can push multiple "references" at once. In the example above I am pushing the tag <tag> and the branch <branch>.

Github however will still trigger multiple actions, I don't think there is a way around that, other than if GitHub changes its implementation.

There is some control you can have about not running repeated actions with the concurrency.cancel-in-progress, but I find that this level of control does not allow me to avoid duplication 100% of the cases.

[Zaloog]

Thanks for your reply,
would be changing the trigger for the gh action a solution then?
I am using the pyscaffold ci.yml workflow:

on:
  push:
    branches: [main]
    tags: ['v[0-9]*', '[0-9]+.[0-9]+*']  # Match tags that resemble a version

do I even need the branches: [main] part then to trigger the gh-action?

[abravalheri]

Would be changing the trigger for the gh action a solution then?

I honestly don't know a good solution for the problem "avoid workflow to run repeatedly if the a branch and a tag referring to the same commit are pushed at the same time" that works 100% of the time. Please let me know if you find a good solution 😅. ¹

do I even need the branches: [main] part then to trigger the gh-action?

That depends on the specific workflow you are using...

The reason why the template used by pyscaffold contains it is that it is meant for being generic and applied to most workflows.

If you block pushes to the main branch for example, you might not need that.
Please note however, that having the CI passing for a PR does not necessarily mean that once you merge the PR, the main branch will also pass (think for example that you have multiple PRs open branching from different points, they might individually pass, but if merged all together they might fail).

Footnotes

1. There is another problem with the concurrency.cancel-in-progress that I forgot to mention: determinism. If you push a tag and a branch at the same time how do you guarantee that github is going to run the job for the tag after the job for the branch so that the job for the branch is cancelled but not the other way around? ↩