fix(ci): move comment workflow to deploy-cd#4814
fix(ci): move comment workflow to deploy-cd#4814riteshfyi wants to merge 23 commits intowebex:nextfrom
Conversation
|
Test Comment Link : riteshfyi#8 (comment) |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 393f72d9e3
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
|
||
| comment-on-pr: | ||
| name: Comment on Released PRs | ||
| needs: [publish-npm, publish-tag] |
There was a problem hiding this comment.
Gate PR release comments on full deploy success
comment-on-pr is intended to run after the full deploy pipeline, but its needs only includes publish-npm and publish-tag. If publish-documentation fails, this job can still post “Your changes are now available,” which is a regression from the previous workflow_run-based flow that only ran when Deploy CD concluded successfully; this can produce incorrect release notifications for partially failed deployments.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
if publish-npm, publish-tag has happened already. then the package is already in production. also publish-documentation gets skipped in some scenarios as well.
| const prs = await github.rest.repos.listPullRequestsAssociatedWithCommit({ | ||
| owner, repo, commit_sha: deploySha | ||
| }); | ||
| const mergedPR = prs.data.find(pr => pr.merged_at); |
There was a problem hiding this comment.
.find() only returns the first merged PR — if multiple merged PRs are associated with this commit (back-to-back merges), the rest get silently skipped? Will this work for that case?
There was a problem hiding this comment.
deploySha is unique for each pull-request, so this won't happen.
|
@vamshigovardhana right now we are fetching 200 comments to verify if we have any pre-exisiting comment, which we can upgrade, like a general one. |
@riteshfyi I think GitHub's API silently caps per_page at 100 -- passing 200 just returns 100 with no error, so increasing the number won't help. why don't we Use github.paginate() instead? which automatically fetches all pages regardless of how many comments exist. |
.github/workflows/deploy.yml
Outdated
| const owner = 'webex'; | ||
| const repo = 'webex-js-sdk'; |
There was a problem hiding this comment.
Can't these be dynamic? Why do we need to hard code these?
There was a problem hiding this comment.
actually it was dynamic earlier, in a review i was suggested to hard-code it, yeah, let's make it dynamic again
| for (const line of raw.split('\n')) { | ||
| const match = line.match(/^__webex_release__:\s+(.+?)\s+=>\s+(.+)$/); | ||
| if (match) packageVersions[match[1].trim()] = match[2].trim(); | ||
| } |
There was a problem hiding this comment.
Why can't this version match happen in the place where we extract __webex_release__: lines?
Seems to be a redundant loop
There was a problem hiding this comment.
just a question kesava, should the job responsible for incrementing the package version, be doing this ?. i feel like it seems a little out of context for that job,
There was a problem hiding this comment.
I did the changes, but that method was very prone to bugs, it introduced 3 bugs which i could identify directly. even after multiple changes, the final appraoch still felt like, that was not good for production. also it was not readable also.
.github/workflows/deploy.yml
Outdated
| const primaryPackage = packageVersions['webex'] | ||
| ? 'webex' | ||
| : packageEntries.filter(([p]) => p !== 'webex' && p !== 'webex-node').map(([p]) => p)[0] || packageEntries[0][0]; |
There was a problem hiding this comment.
This condition seems to check packageVersions['webex'] is matching to the string webex itself. Would this ever match?
.github/workflows/deploy.yml
Outdated
| const primaryVersion = packageVersions[primaryPackage]; | ||
| const stableVersion = primaryVersion.replace(/-next\..*/, '').replace(/-[a-z]*\..*/, ''); | ||
|
|
||
| const changelogUrl = new URL('https://web-sdk.webex.com/changelog/'); |
There was a problem hiding this comment.
This base URL is mapped as a custom domain in the repo.
This setting sits here: https://github.com/webex/webex-js-sdk/blob/next/docs/CNAME
Can we find a way to use this so that we won't have to hardcode this?
.github/workflows/deploy.yml
Outdated
| packagesTable, | ||
| 'Thank you for your contribution!', | ||
| '', | ||
| `_:robot: This is an automated message. For questions, please refer to the [documentation](${repoUrl}#readme)._` |
There was a problem hiding this comment.
We should rather reword this like this:
| `_:robot: This is an automated message. For questions, please refer to the [documentation](${repoUrl}#readme)._` | |
| `_:robot: This is an automated message. For queries, please contact [support](https://developer.webex.com/support)._` |
There was a problem hiding this comment.
Yup, indeed better.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b3a8e0de9f
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
.github/workflows/deploy.yml
Outdated
| echo "$OUTPUT" | ||
| VERSIONS_JSON=$(printf '%s\n' "$OUTPUT" | grep -E '^(@webex/|webex[^ ]*) => ' | \ | ||
| jq -Rn '[inputs | split(" => ")] | map({(.[0]): .[1]}) | add // {}') | ||
| echo "package_versions=$VERSIONS_JSON" >> $GITHUB_OUTPUT |
There was a problem hiding this comment.
Emit compact JSON before setting package_versions output
jq -Rn emits pretty-printed JSON by default, so VERSIONS_JSON contains embedded newlines here; writing it as package_versions=$VERSIONS_JSON produces a multi-line GITHUB_OUTPUT entry, which the runner treats as an invalid output format unless heredoc syntax is used. In runs where packages are incremented, this can fail publish-npm before downstream jobs can read needs.publish-npm.outputs.package_versions.
Useful? React with 👍 / 👎.
.github/workflows/deploy.yml
Outdated
| run: | | ||
| OUTPUT=$(yarn package-tools increment --packages ${{ needs.generate-package-matrix.outputs.node-recursive }} --tag ${GITHUB_REF##*/}) | ||
| echo "$OUTPUT" | ||
| VERSIONS_JSON=$(printf '%s\n' "$OUTPUT" | grep -E '^(@webex/|webex[^ ]*) => ' | \ |
There was a problem hiding this comment.
Tolerate empty increment output when extracting package versions
This pipeline relies on grep producing at least one match, but when no packages are incremented (a case the workflow already models via hasPackages/proceed=false), grep -E exits with status 1 and the step fails under GitHub Actions' bash -eo pipefail defaults. That turns a valid no-package deploy into a hard failure in publish-npm.
Useful? React with 👍 / 👎.
|
@vamshigovardhana @mkesavan13 i'm done with my changes, |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1c9dd0bc52
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| const primaryVersion = packageVersions[primaryPackage]; | ||
| const stableVersion = primaryVersion.replace(/-next\..*/, '').replace(/-[a-z]*\..*/, ''); | ||
|
|
||
| const cnameFile = await github.rest.repos.getContent({ owner, repo, path: 'docs/CNAME' }); |
There was a problem hiding this comment.
Guard CNAME lookup failures before composing comment body
Handle github.rest.repos.getContent({ path: 'docs/CNAME' }) failures before building the release comment, because this call is currently outside the try/catch used for comment posting. If the API call fails (for example due to a transient GitHub API error or a missing/renamed docs/CNAME on the default branch), the comment-on-pr job hard-fails and marks Deploy CD failed even after publish-npm/publish-tag have succeeded.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
should we add a fallback here?


COMPLETES #NA
This pull request addresses
We are moving the pr-comment-workflow to deploy-cd. so we don't have to re-fetch the package changes
by making the following changes
Moves the PR release comment logic from its own workflow into deploy.yml as a final job, so it runs after the full deploy pipeline completes. Uses the increment step output directly for per-package versions instead of re-reading the changelog.
We are logging the output of the yarn increment step during npm-publish to a variable, so we are able to get the updated packages & their latest version.
Change Type
The following scenarios were tested
< ENUMERATE TESTS PERFORMED, WHETHER MANUAL OR AUTOMATED >
The GAI Coding Policy And Copyright Annotation Best Practices
I certified that
Make sure to have followed the contributing guidelines before submitting.