Optimize progress notification

[hyrepo]

Describe the context of this enhancement For some CI/CD systems, i.e. Github Actions, the synchronization has two parts: sync pipeline executions and sync commit history, both of them cost much time. The current implementation of progress notification can't handle a situation like this.

Describe the solution you'd like Use segmented progress, e.g. 50% for executions sync and 50% for commit sync

[RoujingLiu]

We have a thought on this enhancement based on our current work on the Github Actions.

Current Pain Points Fetching runs and fetching commits for runs have no updates of progress to frontend, while only the last step of mapping immediately pass a lot updates to frontend, which cause the progress bar could not really visualize the progress.

Enhancement For fetching runs, we are fetching by pages, while for fetching commits, we are fetching branches first (and by pages as well). So in general, there are two "steps" or "stages". One way to better visualize the progress is to display both which "step" we are, as well as the sub-progress of "page" or "branch". Here is the draft mockup of what we are thinking:

Detailed Changes of the Enhancement

• (FE) Enhance the progress content to support display "steps"
• (FE) Receive the steps information from backend
• (BE) Based on logic flow, pass the step information to frontend during progress update event
• (BE) Beside step information, during fetching pages for runs and fetching branches for commits, also send the progress update event
• (BE) Remove the redundant progress update during runs&commits mapping

[zhe-zhao]

Hi @RoujingLiu , thanks the mockup looks good. In terms of sync steps, here's my $0.02. The main purpose of this progress bar is to give the user a sense how long they have to wait here. According to currently sync process 90% (only a guesstimates value) of time were spent on GA runs sync & commits summary info sync, while the branch info fetching should be relatively faster. Should we consider that when dividing the steps？

[RoujingLiu]

According to currently sync process 90% (only a guesstimates value) of time were spent on GA runs sync & commits s

@zhe-zhao Thanks for the reply!

We do agree that we want to use the progress bar to better visualize the essential progress steps. To further elaborate a bit on our idea related to the "step" for Github Actions based on current logic:

• Step 1: Fetch Runs for all workflows (the detailed progress is based on pages of runs)
• Step 2: Fetch Commits for the branches based on runs to sync (the detailed progress currently plan to based on no. of branches, although we could still use pages but we thought might be too detailed)
• (ignored Step 3): the rest logic like mapping and converting is quite short, so we didn't think worth to put in

Based on our current test in our example, the first two step are quite balanced and should be able to visualize some useful progress.

Hope this make our thought more clear. Do feel free to share more idea :)

[RoujingLiu]

Here is the git for the process bar demo. Hope it gives a clear view of the expected look.

[LixingSun]

Paired with @RoujingLiu we are also going to fix two issues we found during the process:

1. The progress bar label "ant-progress-text" width default is fixed to "2em" and need to modify to "auto" to make it responsive, otherwise will overflow
2. In local development, the frontend didn't receive the SSE message real-time as expected. All are received at once when complete. Based on our research it was due to a legacy "compress" config issue related to webpack dev server. Once set the config to "false" then it will work.