[CI] Release Drafter: duplicate ref on second release candidate?

[qcasey]

I guess we've never made a second release candidate before: https://github.com/paperless-ngx/paperless-ngx/actions/runs/3040356651/jobs/4896819877

Originally posted by @stumpylog in https://github.com/paperless-ngx/paperless-ngx/issues/1560#issuecomment-1244490246

[qcasey]

I'm not sure how this happened. The bulk of the issue is in Create Release and Changelog which silently fails:

Error: Validation Failed: {"resource":"Release","code":"already_exists","field":"tag_name"}

The tag_name being "tag_name":"v1.9.0-beta.rc2". Did anybody manually create the v1.9.0-beta.rc2 prerelease?

Not a critical issue, it just won't upload the release artifact to the prerelease for testing. I could use some help in figuring this one out though.

[stumpylog]

Yeah, it's pretty strange. That tag doesn't (and didn't) exist. I assume the release never has either.

At least the final release should be alright.

[tooomm]

That tag doesn't (and didn't) exist. I assume the release never has either.

There is a v1.9.0-beta.rc2 tag for the project: https://github.com/paperless-ngx/paperless-ngx/tags It's not listed under (pre-) releases though.

[stumpylog]

Slight clarification, it didn't exist before I created it and ran into this

[stumpylog]

I wonder if this is related: paperless-ngx/paperless-ngx: refs/tags/v1.9.0-beta.rc2 is not supported as release target, falling back to default branch

Which I take to mean it maybe is failing back to using main somewhere?

If we set the commitish field to either GITHUB_SHA or GITHUB_REF (probably the SHA?)

[qcasey]

Which I take to mean it maybe is failing back to using main somewhere?

That's my understanding. But the error message crying about tag_name specifically makes me think this warning is unrelated. Although that same warning was on rc1 so maybe?

If defining commitish to GITHUB_SHA doesn't have any side effects let's give it a try?

[stumpylog]

Scratch all that, everything on my fork is A-ok without the commitish. I actually put it in the wrong step anyway.

[stumpylog]

Well, I'm stumped on this. It's like the API is trying to create the tag, instead of creating a release associated with a tag. But why would the first one work then? It's the same process, just a slightly different name.

[qcasey]

stumpylog is stumped? That's a first.

I also can't see a reason this would fail. I'll have more time to test a fix probably after 1.9.0 is released. I'm guessing it's an issue within release-drafter itself rather than our CI configuration.

[stumpylog]

This seems to be working fine now? At least a number of the last RCs and last release, as well as this latest beta and it's first candidate all worked fine.

[shamoon]

Doesnt it only happen when (if) we make a new RC? Maybe i misunderstand so awesome if its fixed

[stumpylog]

The release-drafter only runs on a tag. v1.9.0-beta.rc2 failed, but v1.9.0-beta.rc3, v1.9.0, v1.9.1, v1.9.2 and v1.10.0-beta.rc1 all worked. So it seems to have resolved itself or the network issue is fixed or what have you.

[shamoon]

Oh, gotcha. Sweet!

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.