Import replaceholder workflow from astar-utils

[teutoburg]

The point was always to move it here, but I tested it there first...

This adds the ability to put "PLACEHOLDER_NEXT_RELEASE_VERSION" in the code (usually in docstrings or deprecation warnings and such), which are useful while on the dev version, when it's not final if the next release will be a patch, minor or major. I already started using this placeholder in ScopeSim, the plan is to add workflows that then call the one here, as usual.

Oh and as you can see, it turns out you can actually put regular python code directly into the workflow! My original solution was done in pure bash, but was somewhat lacking and hacky. Also I couldn't escape all those double quotes (believe me I tired, even asked the toaster to no avail), so I ended up putting a single bash line into a separate .sh file. That could also have been done here with the python part, but then there's the issue of calling that script in DevOps, while the workflow itself is run from another repo (in its context and environment). A (not so) quick search revealed that this is indeed a known limitation (what? another one?) of GitHub Actions, and the workarounds are more ugly than just slapping the whole python script directly in here...

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (b24d020) to head (cb472cf).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main       #52   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            2         2           
  Lines            7         7           
=========================================
  Hits             7         7           

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

[hugobuddel]

Meh, I'll approve this, but I think this is moving us too much towards the microsoft-vendor-lock-in trap. Because now we cannot make a release without running github actions.

I mean, we don't want to make releases manually, but we want to be able to. Because then we could easier move to some other CI if we ever want to (or are forced to).

Maybe we could move the code to a regular script in DevOps and then checkout the DevOps repository to run it?

It might not be useful to do that now, so let's just use this.

[teutoburg]

Meh, I'll approve this, but I think this is moving us too much towards the microsoft-vendor-lock-in trap. Because now we cannot make a release without running github actions.

I mean, we don't want to make releases manually, but we want to be able to. Because then we could easier move to some other CI if we ever want to (or are forced to).

I understand the concern, but I don't think this is really limiting us. This workflow is an optional thing, and the action it actually performs (the one find ... sed line) can be run manually locally. In fact I did just that (well, not using that bash line, but an equivalent search-replace option) for the ScopeSim v0.9.3 release, which also had these placeholders, but I didn't have this automated version ready.

Or we could just not use such placeholders and manually write the appropriate version numbers in the docstrings 😉

Maybe we could move the code to a regular script in DevOps and then checkout the DevOps repository to run it?

That was the option I tried to describe above, and rejected because I considered it cleaner to not have to checkout another repo during the workflow call if possible. But yeah, if we (in the future) decide that we do prefer that after all, the python section in here can just be copied to a separate .py script file. Or if we do switch to something else, that works totally different but has the ability to run custom python scripts somehow as part of the release process, we can do that as well. The functional part of the script is fairly isolated I think, all the GitHub output and summary things are optional anyway and the input are just environment variables (which of course could be replaced with command-line arguments if we turn it into a script).