compare-url
compare-url copied to clipboard
iynere
fix new branch ancestor handling flow
The RETURN_CODE was not properly set in cases where the git merge-base --is-ancestor call returned successfully after a previous unsuccessful result.
I tried testing the fix by manually inserting the orb command's content directly in our CircleCI config. It seemed to work for the way I was testing, and the fix intuitively seems like it should resolve the bug. It's admittedly not quite as thoroughly tested as it could be.
Checklist
(Note none of these apply as this is a bug fix)
- [X] All new jobs, commands, executors, parameters have descriptions
- [X] Examples have been added for any significant new features
- [X] README has been updated, if necessary
Motivation, issues
This should fix #25 where a bug in the new branch flow is not properly finding its ancestor.
Description
Fix handling of return code such that the job iteration logic properly identifies the ancestor commit in a new branch flow.
will the job fail if git merge-base --is-ancestor $COMMIT_FROM_JOB_NUM $CIRCLE_SHA1 return 1?
will the job fail if
git merge-base --is-ancestor $COMMIT_FROM_JOB_NUM $CIRCLE_SHA1return 1?
there are no error flags currently set in the embedded bash script (e.g. no set -e, etc.), and it didn't fail in my testing. if that ever changed, it certainly would fail though.
Then I will close my PR #39 , and let's waiting for your PR to be merged. Before that, I'm afraid we have to publish our own orb.
@xdays have you published your version of the orb ?
yes, it's https://circleci.com/orbs/registry/orb/xdays/compare-url
I think we have to handle return code 128 as well.
return code 128 occurs when git merge-base --is-ancestor <A> <B> running with A not registered yet. So when A coming from the job of a different branch, the current branch will not know anything about this A. I think that what makes it returning 128.
Anyway, is this repo still maintainable? I wonder why this PR is never get reviewed by the maintainer.