Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inhibit releases when no changes on code base #3221

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

EjiroLaurelD
Copy link
Contributor

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
Copy link
Collaborator

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

@EjiroLaurelD
Copy link
Contributor Author

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
Copy link
Collaborator

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
Copy link
Contributor Author

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

Screenshot 2024-03-19 145117

@benclifford
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants