Repository navigation
Conversation
gkalpak
added
area: build & ci
IgorMinar
left a comment
IgorMinar
left a comment
There was a problem hiding this comment.
- how slow is slow? a few seconds? a minute? a few minutes?
- also could you credit the original code in https://circleci.com/orbs/registry/orb/iynere/compare-url / https://github.com/iynere/compare-url-orb
It depends on how many builds there have been (on the same branch) since the workflow you are rerunning. For example, if you are rerunning the latest workflow, it would be less than 1sec. But if you are rerunning a workflow from 10 days ago, while there have been hundreds of jobs on the same branch, it may take several seconds or minutes. In a nutshell, we keep "walking" the completed builds backwards (via API requests) until we find the original workflow (i.e. the one that we clicked "rerun" on). So, depending on how many builds there have been since that original workflow, we need to make that many API requests. Note that this slow path will only be used on non-PR builds and only if
Happy to (although all they have in common is the idea of querying the builds via the CircleCI API). |
On push builds, CircleCI provides `CIRCLE_COMPARE_URL`, which we use to extract the commit range for a given build. When a workflow is rerun (e.g. to recover from a flaked job), `CIRCLE_COMPARE_URL` is not defined, causing some jobs to fail. This commit fixes it by retrieving the compare URL from the original workflow. It uses a slow process involving a (potentially large) number of requests to CircleCI API. It depends on the (undocumented) fact, that the `workspace_id` is the same on all rerun workflows and the same as the original `workflow_id`.
0e7b760 to
a1311de
Compare
|
@IgorMinar, PTAL. |
IgorMinar
added
action: merge
|
lgtm. thanks. and sorry that I didn't follow up on this sooner. I didn't realize that it was blocked on me. |
|
@gkalpak can you please clarify one more thing: why didn't you use the "official" workaround https://circleci.com/orbs/registry/orb/iynere/compare-url and instead implemented our own? I'm just curious because you must have had a reason... |
On push builds, CircleCI provides `CIRCLE_COMPARE_URL`, which we use to extract the commit range for a given build. When a workflow is rerun (e.g. to recover from a flaked job), `CIRCLE_COMPARE_URL` is not defined, causing some jobs to fail. This commit fixes it by retrieving the compare URL from the original workflow. It uses a slow process involving a (potentially large) number of requests to CircleCI API. It depends on the (undocumented) fact, that the `workspace_id` is the same on all rerun workflows and the same as the original `workflow_id`. PR Close #27775
In descending order of importantnce:
|
|
Awesome! I knew there was a reason. It's good to have it documented at
least in the pr. It would be even better to document it in the script
itself.
…On Tue, Jan 8, 2019, 12:20 PM George Kalpakas ***@***.*** wrote:
why didn't you use the "official" workaround
https://circleci.com/orbs/registry/orb/iynere/compare-url
In descending order of importantnce:
1. AFAICT (by looking at the code), it would only work if the rerun
workflow is the latest workflow on the branch (which is not guaranteed to
be true).
2. It is less efficient (making unnecessary CircleCI requests for
builds on different branches, having to install extra dependencies,
persisting files to the workspace (as a means of passing the result to the
calling job), etc.).
3. It is slightly more complicated to setup and consume than our own
script.
4. It is more complicated than needed for our usecase (e.g. handling
different git providers, handling newly created branches, etc.).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#27775 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AANM6MAi-3syGxPi7TjLSdd8P5B0xKgkks5vBP2YgaJpZM4ZcPTv>
.
|
Discussed in #27775 (comment). PR Close #28010
Discussed in #27775 (comment). PR Close #28010
On push builds, CircleCI provides `CIRCLE_COMPARE_URL`, which we use to extract the commit range for a given build. When a workflow is rerun (e.g. to recover from a flaked job), `CIRCLE_COMPARE_URL` is not defined, causing some jobs to fail. This commit fixes it by retrieving the compare URL from the original workflow. It uses a slow process involving a (potentially large) number of requests to CircleCI API. It depends on the (undocumented) fact, that the `workspace_id` is the same on all rerun workflows and the same as the original `workflow_id`. PR Close #27775
Discussed in #27775 (comment). PR Close #28010
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
On push builds, CircleCI provides
CIRCLE_COMPARE_URL, which we use to extract the commit range for a given build. When a workflow is rerun (e.g. to recover from a flaked job),CIRCLE_COMPARE_URLis not defined, causing some jobs to fail.This commit fixes it by retrieving the compare URL from the original workflow. It uses a slow process involving a (potentially large) number of requests to CircleCI API.
It depends on the (undocumented) fact, that the
workspace_idis the same on all rerun workflows and the same as the originalworkflow_id.