doc: Add release note for 0.22.0 #1199
Conversation
I'm still quite newbie with ARC - but the notes looked very clear at least to me... :) |
docs/releasenotes/0.22.md
Outdated
|
|
||
| ## GitHub API Cache | ||
|
|
||
| In terms of scalability, ARC now caches GitHub API responses according to their recommendation(=Cache-Control header). |
There was a problem hiding this comment.
do we want to link to the doc https://docs.github.com/en/rest/overview/resources-in-the-rest-api#conditional-requests?
ex: Cache-Control header
There was a problem hiding this comment.
Thanks! Added in e402b2e
docs/releasenotes/0.22.md
Outdated
| The cache for List Runners API is expecially important, as their responses can be shared between every runner under the same scope (repository, organization, or enterprise). | ||
|
|
||
| In previous versions of ARC, the number of List Runners API calls had scaled proportional to the number of runners managed by ARC. | ||
| Thanks to the addition of cache, since v0.22.0, it may scale proportional to the number of runner scopes (=The number of repositories for your repository runners + The number of organizations for your organizational runners + The number of enterprises for your enterprises). You might be able to scale to hundreds of runners depending on your environemnt. |
There was a problem hiding this comment.
maybe with + The number of enterprises for your enterprise runners. 😄
There was a problem hiding this comment.
Good catch 👍 Addressed in e402b2e
docs/releasenotes/0.22.md
Outdated
|
|
||
| In terms of reliability, the first thing to note is that it has a new scale down process for both RunnerDeployment and RunnerSet. | ||
|
|
||
| Previously every runner pod can restart immediately after the completion, while ARC might mark the same runner pod for deletion due to scale down. That resulted in |
There was a problem hiding this comment.
do we want to link to the issue for more context if anyone is interested?
There was a problem hiding this comment.
I think so! e402b2e
|
|
||
| ## Prevention of Unnecessary Runner Pod Recreations | ||
|
|
||
| Another reliability enhancement is based on the addition of a new field, `EffectiveTime`, to our RunnerDeployment and RunnerSet specifications. |
There was a problem hiding this comment.
do we need to highlight what scale mode the EffectiveTime is good for? ex: webhook-based scale vs runner busy-based.
There was a problem hiding this comment.
It's enabled for both modes and there's no way to disable it now. I tried to make it clear in 0f3ead1. Would you mind confirming? 😄
|
Probably #1204 worth covered too. It has a good side-effect of mostly skipping RemoveRunner API calls for ephemeral runners which, in combination with the addition of GitHub API cache, provides us more scalability. |
|
TODO: #1189 needs to be included once we enabled the |
As it turned out to be the biggest release ever, I was afraid I might not be able to write a summary of changes that communicates well. Here is my attempt. Please review and leave any comments so that we can be more confident in this release. Thank you!
mumoshu
force-pushed
the
releasenote-0.22.0
branch
from
0f3ead1
to
0f90f3a
Compare
As it turned out to be the biggest release ever, I was afraid I might not be able to write a summary of changes that communicates well. Here is my attempt. Please review and leave any comments so that we can be more confident in this release. Thank you!