feat(workflows): add gh release instead of ncipollo/release-action

[dzhalaevd]

What was wrong?

Due to security issues with ncipollo/release-action need to remove this dependency and replace with gh release

Closes: #1382
Related: #1382

How it was fixed?

The release logic previously implemented via ncipollo/release-action has been reimplemented using the gh

Our workflow now relied on two key flags:

• allowUpdates: true
• skipIfReleaseExists: true

These flags overlap in behavior at least semantically and the ncipollo documentation doesn't clearly define their interaction or precedence. Based on the existing workflow, i was reimplemented as follows with this idea:

if release exists:
    if draft:
        gh release edit
    if published:
        exit
else:
    gh release create

I tried run jobs for check how release creating here
and re-run for checking how it was updates

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.13%. Comparing base (b6f574c) to head (0dcce49).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1392   +/-   ##
=======================================
  Coverage   95.13%   95.13%           
=======================================
  Files           2        2           
  Lines         473      473           
  Branches       57       57           
=======================================
  Hits          450      450           
  Misses         17       17           
  Partials        6        6           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dzhalaevd]

I think this is ready for review

[seifertm]

First of all, thanks for the initiative of solving this!

I think I understand what process you're aiming for, but we can keep it simpler. Releases are always created from a specific commit hash/tag. If the build is reproducible, the same commit will always lead to the same release artifacts. Therefore, there's no reason to foresee a release being updated or changed.

That means, if a release for a tag is already present, we do nothing. Otherwise, we create a new release. No need to update existing releases.

[seifertm]

Suggested change

	IS_DRAFT=$(gh release view "${TAG_NAME}" --json isDraft --jq '.isDraft' 2>/dev/null || echo "")
	if [ -n "${IS_DRAFT}" ]; then
	if [ "${IS_DRAFT}" = "false" ]; then
	exit 0
	fi
	gh release edit "${TAG_NAME}" \
	--title "pytest-asyncio ${VERSION}" \
	--notes-file release-notes.md \
	--draft
	gh release upload "${TAG_NAME}" dist/* --clobber
	else
	gh release create "${TAG_NAME}" \
	--title "pytest-asyncio ${VERSION}" \
	--notes-file release-notes.md \
	--draft \
	$( [ "${PRERELEASE}" = "true" ] && echo "--prerelease" ) \
	dist/*
	fi
	gh release view "${TAG_NAME}" >/dev/null
	RELEASE_EXISTS=$?
	if [ $RELEASE_EXISTS -ne 0 ]; then
	gh release create "${TAG_NAME}" \
	--title "pytest-asyncio ${VERSION}" \
	--notes-file release-notes.md \
	--draft \
	$( [ "${PRERELEASE}" = "true" ] && echo "--prerelease" ) \
	dist/*
	fi

[seifertm]

I'm not sure if we need to distinguish between VERSION and TAG_NAME in the release title. I know this is the way it's currently handled, but I'd prefer naming releases "pytest-asyncio v1.2.3", instead of "pytest-asyncio 1.2.3".
Any thoughts on this?

[seifertm]

Ah, one more thing: This change isn't user-facing, so it doesn't need a changelog fragment.

(I know it's confusing that chronographer still requests one, but I don't know a better way. Suggestions welcome.)