ci: publish docs artifact for the portal mirror - #26
pratyush618 wants to merge 1 commit into
Conversation
📝 WalkthroughWalkthroughThe documentation workflow now uploads ChangesDocumentation artifact publishing
Estimated code review effort: 1 (Trivial) | ~2 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
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/docs.yml:
- Around line 61-62: Update the artifact upload configuration for docs/out to
set if-no-files-found to error, ensuring the upload fails when the directory
exists but contains no files while preserving the existing missing-directory
failure behavior.
🪄 Autofix
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: 8e535966-e701-46a4-98fc-bf5dbd619e03
📒 Files selected for processing (1)
.github/workflows/docs.yml
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
ByteVeda/taskito(manual) → reviewed against branchci/docs-portal-mirrorinstead of the default branch
| path: docs/out | ||
| retention-days: 90 |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- workflow ---'
sed -n '45,70p' .github/workflows/docs.yml
printf '%s\n' '--- docs output references ---'
rg -n --hidden -S 'docs/out|docs-dist|upload-artifact|download-artifact' .github docs README.md 2>/dev/null || true
printf '%s\n' '--- tracked docs files and build configuration ---'
git ls-files | rg '(^|/)(docs|mkdocs|docusaurus|package.json|pnpm-lock|yarn.lock|package-lock)' | head -200Repository: ByteVeda/dagron
Length of output: 6311
🌐 Web query:
GitHub actions/upload-artifact v7 if-no-files-found default behavior
💡 Result:
For GitHub Actions actions/upload-artifact@v7, the default behavior of the if-no-files-found input is warn [1][2][3]. When set to warn, if the provided path or pattern does not result in any files being found, the action will succeed but will output a warning message in the workflow logs [1][4][3]. Other available options for this input include: - error: Fails the action with an error message if no files are found [2][3]. - ignore: Does not output any warnings or errors, and the action does not fail [2][4].
Citations:
- 1: https://github.com/actions/upload-artifact/blob/main/README.md
- 2: https://github.com/actions/upload-artifact
- 3: https://github.com/actions/upload-artifact?tab=readme-ov-file
- 4: https://github.com/marketplace/actions/upload-a-build-artifact
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- complete docs workflow ---'
cat -n .github/workflows/docs.yml
printf '%s\n' '--- docs package scripts and ignore rules ---'
cat -n docs/package.json
cat -n docs/.gitignore
printf '%s\n' '--- build output configuration ---'
rg -n -C 4 --hidden -S 'out|output|dist|build|static|export' docs/next.config.mjs docs/source.config.ts docs/package.json docs/.gitignoreRepository: ByteVeda/dagron
Length of output: 7015
🌐 Web query:
actions/upload-pages-artifact@v3 if-no-files-found behavior missing path source
💡 Result:
The action actions/upload-pages-artifact@v3 does not support the if-no-files-found input parameter [1][2][3]. This parameter, which allows configuration of whether the action should warn or error when no files are detected, is specific to the actions/upload-artifact action [4][5]. Because actions/upload-pages-artifact is designed specifically for GitHub Pages deployment, it enforces an implicit requirement that files must be present to successfully create a deployable artifact [6]. If no files are found at the specified path, the underlying process typically fails because it cannot generate the necessary artifact for the subsequent actions/deploy-pages step [7][8]. If you are encountering issues where no files are found, consider the following: 1. Verify the path input correctly points to the directory containing your static site files [1][2]. 2. Ensure that your build step successfully generates files in that directory before this action runs [1][7]. 3. If you require more granular control over build failures, you may need to implement separate build and deployment jobs, using actions/upload-artifact with the if-no-files-found option in your build job to explicitly control the failure behavior before passing the artifact to the Pages deployment process [7][8].
Citations:
- 1: https://github.com/actions/upload-pages-artifact
- 2: https://github.com/actions/upload-pages-artifact?tab=readme-ov-file
- 3: https://github.com/marketplace/actions/upload-github-pages-artifact
- 4: https://github.com/actions/upload-artifact?tab=readme-ov-file
- 5: https://github.com/actions/upload-artifact
- 6: Expose actions/upload-artifact if-no-files-found parameter actions/upload-pages-artifact#24
- 7: https://stackoverflow.com/questions/73310631/actions-upload-pages-artifact-fails-at-actions-upload-artifact-with-no-files-we
- 8: https://stackoverflow.com/questions/73310631/actions-upload-pages-artifact-fails-at-actions-upload-artifact-with-no-files-we/73450467
🏁 Script executed (no clone):
#!/bin/bash
set -eu
tmp="$(mktemp -d)"
trap 'rm -rf "$tmp"' EXIT
curl -fsSL https://raw.githubusercontent.com/actions/upload-pages-artifact/v3/action.yml -o "$tmp/action.yml"
curl -fsSL https://raw.githubusercontent.com/actions/upload-pages-artifact/v3/src/upload.ts -o "$tmp/upload.ts" || true
printf '%s\n' '--- upload-pages-artifact action metadata ---'
cat "$tmp/action.yml"
printf '%s\n' '--- implementation references to path/file handling ---'
if [ -s "$tmp/upload.ts" ]; then
rg -n -C 5 'path|tar|file|directory|empty|artifact' "$tmp/upload.ts" || true
fi
Length of output: 2665
🌐 Web query:
site:github.com/actions/upload-pages-artifact "No files were found" upload-pages-artifact
💡 Result:
The error message "No files were found" (or variations such as "No artifacts named 'github-pages' were found") when using actions/upload-pages-artifact typically indicates that the action cannot locate the files you intended to deploy [1][2]. This often occurs for one of the following reasons: 1. Incorrect Path Configuration: The path input in your workflow YAML must point to the correct directory containing your built static files (e.g., _site/, dist/, or build/) [3][4]. If the directory does not exist or the relative path is incorrect relative to your project root, the action will fail [5]. Ensure the path is correct by verifying your build step output location [5]. 2. Outdated Action Versions: If you receive an error stating that no artifacts were found or referencing issues with actions/artifact versions, ensure you are using the most recent version of actions/upload-pages-artifact [2]. Older versions may not be compatible with newer iterations of the underlying artifact storage actions [1][2]. 3. Missing Build Step: The action requires that your files are actually generated before it runs. If your build process failed silently or did not produce the expected directory, upload-pages-artifact will find nothing to upload [6][5]. To troubleshoot, verify your workflow logs to confirm that the build step successfully created the target directory and that the path specified in upload-pages-artifact exactly matches that location [5]. If you continue to encounter issues, check that no other processes have modified or deleted the files between your build step and the upload step [5].
Citations:
- 1: Error: No artifacts named "github-pages" were found for this workflow run actions/upload-pages-artifact#89
- 2: Confusing README? actions/upload-pages-artifact#6
- 3: https://github.com/actions/upload-pages-artifact/
- 4: https://github.com/actions/upload-pages-artifact/blob/main/README.md
- 5:
working-directoryis being ignored actions/upload-pages-artifact#74 - 6: Expose actions/upload-artifact if-no-files-found parameter actions/upload-pages-artifact#24
🏁 Script executed (no clone):
#!/bin/bash
set -eu
root="$(mktemp -d)"
trap 'rm -rf "$root"' EXIT
mkdir "$root/empty"
printf '%s\n' '--- missing directory ---'
if tar --directory "$root/missing" -cvf "$root/missing.tar" --exclude=.git --exclude=.github . >/tmp/pages-tar-missing.log 2>&1; then
echo "unexpected-success"
else
echo "fails"
fi
printf '%s\n' '--- existing empty directory ---'
if tar --directory "$root/empty" -cvf "$root/empty.tar" --exclude=.git --exclude=.github . >/tmp/pages-tar-empty.log 2>&1; then
echo "succeeds"
tar -tf "$root/empty.tar"
else
echo "fails"
fi
Length of output: 202
Reject an empty docs/out directory.
The preceding Pages upload already fails when docs/out is missing. Set if-no-files-found: error so this upload also fails when docs/out exists but contains no files.
🤖 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/docs.yml around lines 61 - 62, Update the artifact upload
configuration for docs/out to set if-no-files-found to error, ensuring the
upload fails when the directory exists but contains no files while preserving
the existing missing-directory failure behavior.
fb2ad0d to
c7863e8
Compare
docs.byteveda.org/<slug>/404s today. GitHub Pages binds a custom domain to exactlyone repository, so this repo cannot serve a subpath of a domain held by
ByteVeda/byteveda.site— setting the domain here just reports already taken byanother repository.
Instead the docs portal mirrors each tool's build into its own export
(ByteVeda/byteveda.site#220).
This repo's own
byteveda.github.io/<slug>/site is unaffected — the docs are copied,not moved.
The portal cannot use the existing
github-pagesartifact:upload-pages-artifacthardcodes a 1-day retention, so it has always expired by the time the portal next
builds (all five tool repos currently report
expired: true). This adds one steppublishing the same directory as
docs-distwith a 90-day retention.No change to how this repo builds or deploys its docs.
Summary by CodeRabbit