feat: add docsearch on deploy plugin - #244
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughThe PR adds a production-gated Netlify plugin that dispatches the Algolia scraper workflow through GitHub Actions. It registers the plugin, updates the Algolia workflow for manual execution and modern output handling, and changes Node.js configuration to version 24.13.0 sourced from Estimated code review effort: 3 (Moderate) | ~22 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
✅ Deploy Preview for absmartly-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@plugins/trigger-algolia-scraper/index.js`:
- Around line 18-26: Wrap the GitHub dispatch fetch call in a try/catch and add
an AbortController-based timeout: create an AbortController, set a timeout (e.g.
setTimeout to call controller.abort after a configurable ms), pass
controller.signal into fetch, and in the catch block handle AbortError and other
network/DNS errors by logging the error and failing gracefully; also check
response.ok after fetch and log/throw with response status/body on non-2xx.
While editing plugins/trigger-algolia-scraper/index.js, update the payload ref
(currently "master") to use a configurable branch variable or confirm/replace
with your production branch name.
- Around line 16-27: The fetch call in plugins/trigger-algolia-scraper/index.js
hard-codes the workflow ref to "master"; replace the static ref in the body
passed to the dispatch fetch (the JSON.stringify({ ref: "master" }) argument)
with Netlify's BRANCH environment variable (e.g., use process.env.BRANCH,
falling back to "master" if unset) so the dispatched workflow uses the actual
deployed branch. Locate the fetch call and update the ref value in the request
body accordingly.
| console.log("Triggering Algolia scraper workflow..."); | ||
|
|
||
| const response = await fetch( | ||
| "https://api.github.com/repos/absmartly/docs/actions/workflows/algolia.yml/dispatches", | ||
| { | ||
| method: "POST", | ||
| headers: { | ||
| Accept: "application/vnd.github+json", | ||
| Authorization: `Bearer ${token}`, | ||
| "X-GitHub-Api-Version": "2022-11-28", | ||
| }, | ||
| body: JSON.stringify({ ref: "master" }), |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's read the file to see the current state
cat -n plugins/trigger-algolia-scraper/index.jsRepository: absmartly/docs
Length of output: 1830
🏁 Script executed:
# Check for Netlify configuration files
find . -name "netlify.toml" -o -name "netlify.json" -o -name ".netlify" -type f | head -20Repository: absmartly/docs
Length of output: 72
🏁 Script executed:
# Look for any deployment or CI/CD configuration
find . -name ".github" -o -name ".gitlab-ci.yml" -o -name "azure-pipelines.yml" -o -name ".circleci" | head -20Repository: absmartly/docs
Length of output: 67
🏁 Script executed:
# Search for any references to BRANCH, HEAD, or other environment variables in the codebase
rg -i "process\.env\.(BRANCH|HEAD|DEPLOY)" --max-count 20Repository: absmartly/docs
Length of output: 40
🏁 Script executed:
# Read the netlify.toml to check if multiple branches are deployed to production
cat netlify.tomlRepository: absmartly/docs
Length of output: 117
🏁 Script executed:
# Check the GitHub workflows
ls -la .github/workflows/Repository: absmartly/docs
Length of output: 354
🏁 Script executed:
# Search for context or branch references in the entire codebase
rg -i "context.*production|branch" netlify.toml .github/ | head -30Repository: absmartly/docs
Length of output: 2786
🏁 Script executed:
# Read the algolia.yml workflow to see what it expects
cat .github/workflows/algolia.ymlRepository: absmartly/docs
Length of output: 656
🏁 Script executed:
# Read the build.yml to check production deployment configuration
cat .github/workflows/build.ymlRepository: absmartly/docs
Length of output: 645
🏁 Script executed:
# Search for Netlify configuration related to production deployments
rg "production|branch" netlify.tomlRepository: absmartly/docs
Length of output: 40
🌐 Web query:
Netlify environment variables BRANCH production deploy
💡 Result:
On Netlify, “production vs branch deploy” is determined by the deploy context, not by whether BRANCH is set.
-
Detect production deploys
- Use the built-in read-only env var
CONTEXT:CONTEXT=productionfor deploys from your site’s configured production branchCONTEXT=branch-deployfor deploys from non-production branches- (also
deploy-previewfor PR previews,devfor Netlify Dev) [1][2]
- Use the built-in read-only env var
-
What
BRANCHmeansBRANCHis a built-in read-only variable that contains the Git branch name being built (including on production deploys, where it will be your production branch likemain) [2].
-
Setting different env var values for production vs branch deploys
- In the Netlify UI you can set contextual values per deploy context (
Production,Branch deploys,Deploy Previews, etc.) and optionally override for a specific branch (or a wildcard likerelease/*). The branch-specific value wins for that branch’s deploys. [3][4]
- In the Netlify UI you can set contextual values per deploy context (
-
Doing it in
netlify.toml- You can set context-specific env vars like:
[context.production.environment]for production[context.branch-deploy.environment]for branch deploys[context.<branchname>.environment]for a specific branch (most specific wins) [5]
- You can set context-specific env vars like:
Sources:
[1] Netlify Docs — Build environment variables (read-only CONTEXT, BRANCH)
[2] Netlify Docs — File-based configuration (context names and what “production” means)
[3] Netlify Docs — Environment variables overview (contextual values, branch overrides, wildcards)
[4] Netlify Blog — Introducing Deploy Contexts
[5] Netlify Docs — Get started with environment variables (netlify.toml context env examples)
Use the deployed branch name instead of hard-coding "master".
If production deploys from both the master and development branches (as shown in build.yml), dispatching the workflow to a static ref will fail on deployments from non-master branches. Use Netlify's BRANCH environment variable, which contains the actual Git branch being deployed:
♻️ Suggested ref handling
const token = process.env.GITHUB_PAT;
if (!token) {
utils.status.show({
title: "Algolia scraper trigger skipped",
summary: "GITHUB_PAT environment variable is not set.",
});
return;
}
+ const ref = process.env.BRANCH || "master";
console.log("Triggering Algolia scraper workflow...");
@@
- body: JSON.stringify({ ref: "master" }),
+ body: JSON.stringify({ ref }),🤖 Prompt for AI Agents
In `@plugins/trigger-algolia-scraper/index.js` around lines 16 - 27, The fetch
call in plugins/trigger-algolia-scraper/index.js hard-codes the workflow ref to
"master"; replace the static ref in the body passed to the dispatch fetch (the
JSON.stringify({ ref: "master" }) argument) with Netlify's BRANCH environment
variable (e.g., use process.env.BRANCH, falling back to "master" if unset) so
the dispatched workflow uses the actual deployed branch. Locate the fetch call
and update the ref value in the request body accordingly.
There was a problem hiding this comment.
Deployments from development are not production deploys - only master should trigger the doc search scrape
There was a problem hiding this comment.
@calthejuggler, thank you for the clarification! You're absolutely right—if only master is deployed to the production context, then hard-coding ref: "master" is the correct approach. The CONTEXT === "production" check already ensures the workflow only triggers for production deploys from master, making the static ref appropriate for your deployment model.
✏️ Learnings added
Learnt from: calthejuggler
Repo: absmartly/docs PR: 244
File: plugins/trigger-algolia-scraper/index.js:16-27
Timestamp: 2026-01-26T10:45:26.591Z
Learning: In the absmartly/docs repository, only the `master` branch is deployed to Netlify's production context. Deployments from the `development` branch are not production deploys and should not trigger the Algolia DocSearch scraper.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
d56fb4f to
cc1943a
Compare
✅ Deploy Preview for absmartly-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
62e4fd0 to
2300699
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/algolia.yml:
- Line 10: Disable persisted checkout credentials on both actions/checkout
steps: add persist-credentials: false in .github/workflows/algolia.yml at lines
10-10 and .github/workflows/build.yml at lines 13-13.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 22cc1bdb-86a6-41b1-9dfd-562dd9f04290
📒 Files selected for processing (3)
.github/workflows/algolia.yml.github/workflows/build.yml.nvmrc
🚧 Files skipped from review as they are similar to previous changes (1)
- .nvmrc
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's internal server error or limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/algolia.yml:
- Line 10: Disable persisted checkout credentials on both actions/checkout
steps: add persist-credentials: false in .github/workflows/algolia.yml at lines
10-10 and .github/workflows/build.yml at lines 13-13.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 22cc1bdb-86a6-41b1-9dfd-562dd9f04290
📒 Files selected for processing (3)
.github/workflows/algolia.yml.github/workflows/build.yml.nvmrc
🚧 Files skipped from review as they are similar to previous changes (1)
- .nvmrc
🛑 Comments failed to post (1)
.github/workflows/algolia.yml (1)
10-10: 🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash set -euo pipefail for f in .github/workflows/algolia.yml .github/workflows/build.yml; do echo "===== $f =====" nl -ba "$f" | sed -n '1,120p' doneRepository: absmartly/docs
Length of output: 234
🏁 Script executed:
#!/bin/bash set -euo pipefail for f in .github/workflows/algolia.yml .github/workflows/build.yml; do echo "===== $f =====" awk 'NR>=1 && NR<=120 { printf "%4d %s\n", NR, $0 }' "$f" doneRepository: absmartly/docs
Length of output: 1724
Disable persisted checkout credentials in both workflows.
actions/checkoutleaves the repository token in git config by default, so later steps can reuse it. Setpersist-credentials: falseon both checkout steps:
.github/workflows/algolia.yml:10.github/workflows/build.yml:13🧰 Tools
🪛 zizmor (1.26.1)
[warning] 10-10: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
📍 Affects 2 files
.github/workflows/algolia.yml#L10-L10(this comment).github/workflows/build.yml#L13-L13🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/algolia.yml at line 10, Disable persisted checkout credentials on both actions/checkout steps: add persist-credentials: false in .github/workflows/algolia.yml at lines 10-10 and .github/workflows/build.yml at lines 13-13.Source: Linters/SAST tools
Pedro-Revez-Silva
left a comment
Pedro-Revez-Silva
left a comment
There was a problem hiding this comment.
Looks good overall. I’m approving with one non-blocking P2 reliability concern inline.
| } catch (error) { | ||
| console.error("Failed to reach the GitHub API:", error.message); | ||
| utils.status.show({ | ||
| title: "Algolia scraper trigger failed", | ||
| summary: `Could not reach the GitHub API: ${error.message}`, | ||
| }); | ||
| return; |
There was a problem hiding this comment.
[P2] Please make scraper-dispatch failures operationally visible. A missing token, a network/timeout error here, or the non-2xx path below currently only calls utils.status.show(...) and returns. Now that the push: master trigger is removed, that can leave search stale with no failed GitHub workflow or automatic retry. I’d retry transient failures and then call utils.build.failPlugin(...) (or provide equivalent alerting). This does not need to block this PR if best-effort indexing is intentional, but that behavior should be an explicit operational choice.
2300699 to
e4a8353
Compare
2 participants
Previously, our DocSearch scraper was running immediately when a PR was merged. This creates a race condition where the scrape happens on the /previous/ version of the docs site - not the new one.
This PR adds a deployment plugin that,
onSuccess, runs the search scraper.What changed
plugins/trigger-algolia-scraper) that fires ononSuccess. On production deploys only, it dispatches thealgolia.ymlworkflow via the GitHub API so the scraper runs against the freshly published site.algolia.ymlno longer triggers onpush: master— it is nowworkflow_dispatch-only, driven by the plugin (also migrated the deprecated::set-outputto$GITHUB_OUTPUT).build.ymlreads the Node version from.nvmrc(node-version-file) instead of a hardcoded20.x, and.nvmrcis bumped to24.13.0.Setup required (Netlify env var)
The plugin reads
GITHUB_PATfrom the Netlify build environment. This is not the GitHub ActionsGITHUB_TOKEN(that only exists inside an Actions run; this plugin runs in Netlify's build). Provision it as:absmartly-botaccount's token (not a personal PAT), ideally a fine-grained PAT scoped toactions: writeonabsmartly/docsonly.How to test
Triggering Algolia scraper workflow...followed by the success status, and that a newAlgoliaworkflow run appears in the Actions tab.Jira: N/A (docs-site CI/build tooling)
Summary by CodeRabbit