compare-url orb not working reliably #83
Comments
That approach has a weakness that the job will definitely fail if the current branch does not on the same level as the current master. Like, when there is a PR landed on the master branch. Another PR that still open won't have the same level of git history as the current master until they pull the current master. Despite that weakness, I think it still the best approach we can use for now. To do that, we need to research the CircleCI API docs to find whether it is possible to get the latest commit hash from the latest current master. |
|
I think |
|
One possible approach to get the last commit hash from the master branch is by running the same script as to get the last commit hash from the last job but with a filter to find "master" branch first before getting the commit hash. When the branch is not master: $ curl -u <circleci_token>: https://circleci.com/api/v1.1/project/github/oshimayoan/monorepo-example/16 | grep '"branch"'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--100 40484 0 40484 0 0 21688 0 --:--:-- 0:00:01 --:--:--100 40484 0 40484 0 0 21684 0 --:--:-- 0:00 "branch" : "pull/1",
:01 --:--:-- 21683
"branch" : "pull/1",When the branch is master: $ curl -u <circleci_token>: https://circleci.com/api/v1.1/project/github/oshimayoan/monorepo-example/14 | grep '"branch"'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--100 15278 0 15278 0 0 9633 0 --:--:-- 0:00:01 --:--:--100 40458 0 40458 0 0 25493 0 --:--:-- 0:00:01 --:--:-- 25493
"branch" : "master",
"branch" : "master",But for that, we need to loop that script until it finds the "master" branch. And of course, this approach also has a weakness of a race condition when a PR been landed when the CI still looping the script. There is a chance that the last commit has that being found will not be the last commit hash from the latest master. But is it okay? In my opinion, it's still forgivable if we can't find any other solution for this. |
|
There is another approach by using the ENV variable to store the last commit hash from the latest master branch. Basically, we make a filter based on the branch. So every time CircleCI running a job on the master branch, not a PR, we will get the HEAD commit hash and store it inside an ENV variable that we created it before. That ENV variable will always change every time a job is running on the master branch. This approach is actually better than the previous approach, in my opinion. And also this seems more reliable than the previous one. |
|
I've made a fork of |
|
OK, so I was wrong all this time. Current One of the problems we often got is related to this issue iynere/compare-url#25. Regarding that issue, I think I found a fix for that, for sure. On the source code, I print the value of So take a glance at this: COMMIT_FROM_JOB_NUM= a525c2f94ccd761b3bc13efe0163bc6f5cc75bc6
CIRCLE_SHA1= b52f3cbc582f155c613d13cb831bec7d361a05cf
RETURN_CODE= 1
----------------------------------------------------------------------------------------------------
commit a525c2f94ccd761b3bc13efe0163bc6f5cc75bc6 from job 25 is not an ancestor of the current commit
----------------------------------------------------------------------------------------------------On job 25, actually, it's a job that ran for master branch and the latest commit is This happens because when |
|
I put the fix in this branch https://github.com/oshimayoan/compare-url/tree/fix-new-branch-fail |
|
Another problem is when a PR is getting a Because So this will happens: Commit range: b52f3cbc582f...b41423c44770
fatal: ambiguous argument 'b52f3cbc582f...b41423c44770': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
project-a not modified; no need to test
fatal: ambiguous argument 'b52f3cbc582f...b41423c44770': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
project-b not modified; no need to testWhen this happens, all tests will be skipped by the CircleCI because it doesn't find any changes from each package/project. And the job will be marked as PASSED because there is no failing test. |
|
OK, after playing around a little more I grasp more understanding over this. So the problem with Take a look at this line https://github.com/oshimayoan/compare-url/blob/d883d438cea6d74634fed86b4717a69d98144562/src/commands/reconstruct.yml#L83 To solve this problem, we have to find a way how to tell the orb to mark the branch as a new branch again when the branch got a |
|
And for another issue with fatal: Not a valid commit name a3bea042dd0e826aeca3c51fc5358ac2c7ec03a6
COMMIT_FROM_JOB_NUM= a3bea042dd0e826aeca3c51fc5358ac2c7ec03a6
CIRCLE_SHA1= 3337fc2d1878ad13368ae631ba66b301f73775eb
RETURN_CODE= 128
unknown return code 128 from git merge-base with base commit a3bea042dd0e826aeca3c51fc5358ac2c7ec03a6, from job 35
Exited with code 1
I've tried to add Reference: https://discuss.circleci.com/t/git-command-i-returned-128/5333/13 |
|
Alright, I think I found another clue regarding It seems this issue occurs when I tried it on my terminal with git know about $ git merge-base --is-ancestor a3bea042dd0e826aeca3c51fc5358ac2c7ec03a6 0bfed20198aef72a8953213232512bd0ae40fa00
$ echo $?
1Here is when I tried it with unknown $ git merge-base --is-ancestor a3bea042dd0e826aeca3c51fc5358ac2c7ec03ax 0bfed20198aef72a8953213232512bd0ae40fa00
fatal: Not a valid object name a3bea042dd0e826aeca3c51fc5358ac2c7ec03ax
$ echo $?
128So we have to handle that |
|
OK, I have solved the issue with Here is the workflow when the issue is fixed: |
|
Finally, OK, so when the function If there is no ancestor found, we can assume the branch is got a Here is the result: |
What happened
Currently, the orb gets the last commit hash from the previous job as the left side of the commit range. That's what makes the CI failed because the left side of the commit range is not registered either in master or current branch.
This is what we got when it happened. This is happened on
reconstructsection.fatal: Not a valid commit name a23f024ca0fe8e1c39329e2609f940087a851319 unknown return code 128 from git merge-base with base commit a23f024ca0fe8e1c39329e2609f940087a851319, from job 12 Exited with code 1It telling us that
a23f024ca0fe8e1c39329e2609f940087a851319is not a valid commit name. Of course, it is not, because that commit is retrieved from job 12 which is a job for different PR. So it will happen when there is another PR running CI after another PR run.Expected behaviour
The last commit hash from master should be the one being used here instead of the last commit hash from the previous job.
The text was updated successfully, but these errors were encountered: