inhibit releases when no changes on code base

[EjiroLaurelD]

Description

This is a suggested workflow implementation to reduce the risk of automatic releases for unchanged codebases, promoting better release management practices as raised in #2616

Changed Behaviour

The workflow leverages the release-check action to specifically target changes in the codebase, directly addressing the goal of inhibiting releases for unchanged code.

Which existing user workflows or functionality will behave differently after this PR?

I built the workflow leveraging the existing workflow on #2617 as a guide.
I included the gr2m/release-check action which analyzes the changes in the pushed code.

Fixes

The action gr2m/[email protected] is designed to help determine whether a push or pull request in a GitHub repository warrants creating a release. It focuses on changes that directly affect the codebase logic, excluding changes related to packaging or documentation.

Fixes # (issue)

Type of change

Choose which options apply, and delete the ones which do not apply.

• New feature
• fixes

[benclifford]

do you have a link for that gr2m/release-check action? I'm struggling to find it using Google.

[EjiroLaurelD]

do you have a link for that gr2m/release-check action? I'm struggling to find it using Google.

I got the recommendation from Gemini. I can't seem to find any documentation on a Google search aswell.
This is the gemini link below

https://g.co/gemini/share/8430108fa9df

[benclifford]

OK. Did you test the changes this PR introduces? You won't be able to try a full parsl release, but you can at least try out some of the steps in your own github repo, I think, perhaps even without touching parsl at all, to make sure you understand what is going on here. It's hard to test a release process PR like this in the Parsl repo (and that's why my previous attempt didn't work) but it would be good to see some tests in a different repo that show the new release behaviour mostly works.

[EjiroLaurelD]

Hi @benclifford
I am sorry I have been away, I had some issues with my laptop but it has been fixed.
I modified the workflow to test in my repo as you suggested. I think it's going to work now, but it's failing at the "publish package" step. I am guessing it is permission issue but i'm unsure. Please review, looking forward to your thoughts on this

[benclifford]

yes, I would expect this to be forbidden for you at the publish package step - but you should be able to see in your tests:
i) if there is a change, publishing should be attempted (even though it fails for you because of permissions)
ii) if there is no change, publishing should not be attempted.

Both of those behaviours are important, so make sure believe that your PR behaves both ways.