👷(CLDSRV-860) Monitor async await migration#6088
👷(CLDSRV-860) Monitor async await migration#6088DarkIsDude wants to merge 8 commits intodevelopment/9.3from
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
93020af to
8981239
Compare
This comment was marked as resolved.
This comment was marked as resolved.
|
|
||
| if (process.env.GITHUB_STEP_SUMMARY) { | ||
| const { writeFileSync, appendFileSync } = await import('node:fs'); | ||
| appendFileSync(process.env.GITHUB_STEP_SUMMARY, [ |
There was a problem hiding this comment.
do we really want a summary in every PR?
for monitoring the progress, this may be done in a separate job (eg. nightly on on dev branches) which builds a report giving the status on the "latest branch" (as a badge in the README, as a GitHub page, ....)
There was a problem hiding this comment.
IMO we can keep it simple as compute the report in each PR. Not a big deal, it's only some seconds so no finance impact.
There was a problem hiding this comment.
I was not thinking about build time or finance, but really about relevance:
- a summary is "inside" the build, so people will not go look at it - not will it show them how much progress they made (in their PR)
- for "monitoring", i.e. if someone want to (periodically...) check the status : not sure it is very practical to just go and look inside the last finished build
the summary does not hurt I agree, but I'd rather have something more dedicated to their purpose, like
- a report in a "static" place : GitHub page, badge in the Readme, periodic reporting job...
- a comment on the PR indicating how this specific PR affected the async migration (like "Great, you removed 10 async calls! Migration is now 53% complete, keep pushing!")
There was a problem hiding this comment.
That's a good point 🙏. Let's start simple again and I'll add your comment. We don't know how this will be use and what is needed from the team/dev. So I suggest to not waste time on that and iterate when we have feedback ?
There was a problem hiding this comment.
We don't know how this will be use and what is needed from the team/dev
That is not really true : this work was started because you wanted to solve a problem, i.e. gaining visibility on progress of the migration I think.
And my point here is really simple : does the summary approach give you that visibility?
There was a problem hiding this comment.
should these scripts not be in the Guidelines repo, so they can be reused?
(and if needed, it may include a github action as well)
There was a problem hiding this comment.
Right now as it's the first repo, I would keep them here. When will be migrated to an another repo, can be. Maybe with a claude skills also 🤷
There was a problem hiding this comment.
Right now as it's the first repo, I would keep them here
why do you say that?
Do we expect to have to iterate on these scripts, and need "closeness" with the code? Or do you think the script are kind of tailored to cloudserver, and would not work as such in other code base?
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
a64c535 to
f1e7018
Compare
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
f1e7018 to
c4d81e1
Compare
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
f3ff7ea to
8612e12
Compare
This comment was marked as resolved.
This comment was marked as resolved.
| if (fn.isAsync()) continue; | ||
|
|
||
| const startLine = fn.getStartLineNumber(); | ||
| if (!addedLines.has(startLine)) continue; |
There was a problem hiding this comment.
is this the right filter?
This would consider only functions whose "header" is changed : and skip if only an update is made inside the existing function's body...
should we not search that there are no addedLines between fn.getStartLineNumber() and fn.getEndLineNumber() (or however it is called)
There was a problem hiding this comment.
That's a good comment that I didn't notice. Anyway I suggest to keep current behaviour. We can start "slowly" and not too aggressive. This will allow dev to be familiar with async/await and introduce not too much change at the start. I'll add a comment in the guideline to setup your suggestion in some months ?
There was a problem hiding this comment.
There was a problem hiding this comment.
I understand the iterative approach, but I think it would be really too limited to only require await migrations on signature changes -- they change very rarely, not sure signature only is significant enough for a first iteration.
delthas
left a comment
There was a problem hiding this comment.
LGTM on the whole (agree we can iterate later)
| console.log(`Total functions: ${totalFunctions}`); | ||
| console.log(`Async functions: ${asyncFunctions} (${asyncFunctionPercent}%)`); | ||
| console.log(`Callback functions: ${callbackFunctions}`); | ||
| console.log(`Remaining .then(): ${thenChains}`); |
There was a problem hiding this comment.
should we also count "dual-style" functions (async + cb)?
|
|
||
| if (process.env.GITHUB_STEP_SUMMARY) { | ||
| const { writeFileSync, appendFileSync } = await import('node:fs'); | ||
| appendFileSync(process.env.GITHUB_STEP_SUMMARY, [ |
There was a problem hiding this comment.
We don't know how this will be use and what is needed from the team/dev
That is not really true : this work was started because you wanted to solve a problem, i.e. gaining visibility on progress of the migration I think.
And my point here is really simple : does the summary approach give you that visibility?
| run: yarn run --silent lint -- --max-warnings 0 | ||
| - name: Lint Javascript (strict, excluding async migration rules) | ||
| run: | | ||
| yarn run --silent lint -- --max-warnings 0 --rule "promise/prefer-await-to-then: off" --rule "n/callback-return: off" |
There was a problem hiding this comment.
should these rule exceptions not be added in the package.json instead?
so that developer can run yarn lint locally as well...
or do we expect developers to run lint with this rule, and be smart about ignoring them?
| "promise/prefer-await-to-then": "warn", | ||
| "n/callback-return": "warn", |
There was a problem hiding this comment.
- kind of redundant with the dedicated linter you added
- in CI : disabled
- in dev : since we migrate "function by function", there will probably be lots of warnings there... which may make the lint practically useless (too hard to use, too many warnings to ignore) for devs?
i.e. should we really add these now?
https://scality.atlassian.net/wiki/spaces/OS/pages/3523346468/2025-10-30+-+Async+Await+migration