Feature/upload to releasename

[malud]

This PR adds an option to upload the given file asset to an existing draft release.

Prevent mailing users for (pre)release events without assets. Enables reaction to build fails before release promotion.

Would be nice if we could propagate this -draft option to https://github.com/wangyoucao577/go-release-action .

[wangyoucao577]

@malud Do you mean the client.Repositories.GetReleaseByTag can not return DRAFT release?
I did a simple test below shows that it works well:

curl -H "Accept: application/vnd.github.v3+json" "https://api.github.com/repos/wangyoucao577/assets-uploader/releases/tags/v0.7.0"
{
  "url": "https://api.github.com/repos/wangyoucao577/assets-uploader/releases/53251096",
  "assets_url": "https://api.github.com/repos/wangyoucao577/assets-uploader/releases/53251096/assets",
  "upload_url": "https://uploads.github.com/repos/wangyoucao577/assets-uploader/releases/53251096/assets{?name,label}",
  "html_url": "https://github.com/wangyoucao577/assets-uploader/releases/tag/v0.7.0",
  "id": 53251096,
  "author": {
    "login": "wangyoucao577",
    "id": 1905370,

...

It seems that nothing need to do, just fill in the tag of the DRAFT release. Have a try please!

[malud]

@wangyoucao577 In my case I create a draft release by branch, maybe push additional commits and tag later. Until this point this release is untagged. The result is then a 404.

[wangyoucao577]

@wangyoucao577 In my case I create a draft release by branch, maybe push additional commits and tag later. Until this point this release is untagged. The result is then a 404.

We can only identify a release by tag with Github's API, whatever it's draft or not. On the other hand, there might be many draft releases in a repo, so the draft flag can not help to identify a release.
So make sure your release and tag correctly binded, then your assets will be published to the place you want.

[malud]

We can identify all releases by listing them: https://docs.github.com/en/rest/reference/releases#list-releases

This returns a list of releases, which does not include regular Git tags that have not been associated with a release.

As said, my release MAY be untagged and MAY be tagged in my workflow. However, your point is the weak reference to the first found draft? We could change the flag type from bool to string to identify a draft release by its name. Maybe sorted by createat-date. Would you accept this change?

[wangyoucao577]

We can identify all releases by listing them: https://docs.github.com/en/rest/reference/releases#list-releases

This returns a list of releases, which does not include regular Git tags that have not been associated with a release.

As said, my release MAY be untagged and MAY be tagged in my workflow. However, your point is the weak reference to the first found draft? We could change the flag type from bool to string to identify a draft release by its name. Maybe sorted by createat-date. Would you accept this change?

Will you strongly need it's draft? I think the logic could be simpler: 1) try to find the release by tag; 2) if not find, try to list the releases(as you said, descending sorted by create date) and find the release by releasename. I.e., change -draft to -releasename, and don't need to care about whether it's draft or not. How do you think?

[malud]

@wangyoucao577 I have changed the option to releasename as suggested. RFR.

[wangyoucao577]

@wangyoucao577 I have changed the option to releasename as suggested. RFR.

@malud Thanks!