Minimize versioned references to PTB's python-environment/action.yml

[ckunki]

Lately, we had frequent updates on the PTB GitHub workflow action python-environment/action.yml.

Let's celebrate that only a single place needed to be updated: the PTB -- which is a great achievement in my eyes.

However, each new release of the PTB requires each of our projects using the PTB to update the version in ~ 20 references to the PTB action. In ~ 20 projects, these are 400 lines of code.

Additionally, references in custom workflows (contained in some projects) need to be updated manually, as the PTB only updates the workflows that are generated by itself.

Proposal

How about adding a local (unversioned) action.yml to each project in order to reduce these updates?

The PTB could still generate and update the project's action.yml with the command tbx worflow update. Alternatively the project's action.yml could itself contain a reference to the latest version of the PTB's action, in this case only a single file needs to be updated.

[tomuben]

Could this hit again this invocation limit from Github (I believe we could have at max 3 nested workflows, I believe we had this problem here)?

[tkilias]

Could this hit again this invocation limit from Github (I believe we could have at max 3 nested workflows, I believe we had this problem here)?

An action is not a workflow, I think, the action actually runs inside the workflow itself, so hopefully not, but maybe something we need to test.

[tomuben]

Another approach would be that we do not pin a specific version, like exasol/python-toolbox/.github/actions/python-environment@1.2.0, but a major version, like exasol/python-toolbox/.github/actions/python-environment@1. Then Github will automatically use the latest version 1.*). We do that already with many other external GH actions.

[tomuben]

Another approach would be that we do not pin a specific version, like exasol/python-toolbox/.github/actions/python-environment@1.2.0, but a major version, like exasol/python-toolbox/.github/actions/python-environment@1. Then Github will automatically use the latest version 1.*). We do that already with many other external GH actions.

I just tested this approach, but it does not work out of the box, see https://github.com/exasol/script-languages-container-tool/actions/runs/16810839542/job/47615470103?pr=314.

After some investigation, I saw that other people solve this issue by having two tags for a release: "1.7.4" and "v1" in our case. Then every time the PTB would create a new 1.* release it would need to overwrite the "v1" tag.....
I don't find this solution too bad.