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 (f3278d7).
⚠️ Report is 13 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]

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.)

[dzhalaevd]

I think we can add label for PR like internal or smth else, which allow skip this step in CI, but then we need to triage PRs. If this sounds good, I can open a follow-up issue for this, since it’s out of scope for this PR