---
# System prepended metadata

title: Debunking github-actions based releases

---

# Debunking github-actions based releases

GitHub Actions are very poorly documented, change often and debugging them is in most cases done in-production.

I will try to document some tricks I found the hard way. 

## Condition step for release tags only

```yaml
      if: >-
        github.event_name == 'push' &&
        github.event.ref_type == 'tag' &&
        github.ref == 'refs/heads/${{ github.event.repository.default_branch }}'
```


## Events will not trigger for recreated tags
If you fail to make a release when doing a particular tag and you hope that removing the tag and the release and recreating them will fix, you will be surprised.

GitHub does not document this anywhere but what happens is that if an even for push-tag was ever created for the same tag name, it will not be created again when you create the tag after deleting it.

Your only option is to create incremental tags and never to re-use existing ones. So, don't ask me why there is only a 1.0rc2 without an 1.0rc1 so.


## Do not try to use release events

There are lots of events related to release like release, prerelease and publish but going that route seems to guarantee only pain and unexpected behaviors. Despite their simple names, when they really happen is not really clear and editing a release or changing it tag would suprise it.

That is at least for the moment I find push events with ref_type tag being more reliable, and these also have the advantage of being triggered for both case: release created using web interface or using git push.