-
Notifications
You must be signed in to change notification settings - Fork 17
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
Allow filtering by job id #11
Conversation
@iamnafets I've reviewed the changes and noticed the change to the behaviour if no matching run has been found. Previously the current SHA was returned, but with this PR the earliest SHA will be returned instead. Is there a specific reason for this change? |
+1 for this PR to be approved, you should not use the triggeringSHA if you cannot find a successful run. A good use-case for this action is that you can use it for checking if a scheduled build can be skipped when the sha has been built before. It currently breaks on the first build of a workflow or if all builds in a workflow has failed, then the github.sha and last-succesful-build.outputs.sha will always be equal. Also the name "last-successful-build" is misleading since it can return the triggering sha even though it does not correspond to a succesful build. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will merge the PR but add another option to control what should be done when no build was found. I was not able to determine of the changed behaviour will break no existing behaviour in our builds.
Some workflows you may want to filter by the last workflow with a specifically-named successful job. This PR adds an additional parameter to do this.