Skip to content

Read up on GH release workflow in case workflow can be improved #293

@masklinn

Description

@masklinn

Just (re?) discovered that the release hook has a ton of sub-events (published, unpublished, created, edited, deleted, prereleased, released). This is mostly relevant to the native package as its release tests are a lot more involved than the pure python, but I should eventually explore whether it's possible to block a release without "wasting" a tag.

Sadly from a quick test it looks like even just creating a prerelease "burns" the tag, if things don't work out you have to either create a brand new tag, or delete the release and tag, both of which are... ugh.

Also

Workflows are not triggered for the created, edited, or deleted activity types for draft releases. When you create your release through the GitHub UI, your release may automatically be saved as a draft.

So at a glance it feels like the release system has a ton of completely useless / unused complexity?

Also doesn't look like there's a good way to handle workspace, looks like it's just pseudo-namespacing via tag names, essentially what I did on https://github.com/ua-parser/uap-rust

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions