-
-
Notifications
You must be signed in to change notification settings - Fork 11
Nightly builds #115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Nightly builds #115
Conversation
|
Note
|
| Cohort / File(s) | Summary |
|---|---|
Reusable Build Workflow .github/workflows/build.yaml |
New reusable workflow defining a PlatformIO build job: checkout, pip & PlatformIO cache restore, Python 3.11 setup, install PlatformIO Core via pip, and run pio run. |
CI Workflow Refactor .github/workflows/ci-pio.yaml |
Replaced inline build job steps with a call to the reusable build.yaml workflow; workflow now triggers on push and pull_request and delegates build execution. |
Nightly Release Workflow .github/workflows/nightly.yml |
New scheduled/manual workflow (02:00 UTC) that calls the reusable build, downloads build artifacts, generates a changelog (sinceTag v0.8.0), and publishes a nightly prerelease with *.bin/*.bin.gz attachments. |
Sequence Diagram
sequenceDiagram
participant Trigger as Schedule/Manual Trigger
participant GHA as GitHub Actions
participant BuildWF as Build Workflow (build.yaml)
participant Artifacts as Artifact Storage
participant ChangelogGen as Changelog Generator
participant Release as Release Publisher
Trigger->>GHA: invoke nightly workflow
GHA->>BuildWF: call reusable build workflow
BuildWF->>BuildWF: checkout, setup, install pio, run build
BuildWF->>Artifacts: upload *.bin, *.bin.gz artifacts
GHA->>Artifacts: download artifacts in nightly job
GHA->>ChangelogGen: generate changelog since v0.8.0
ChangelogGen-->>GHA: return changelog content
GHA->>Release: publish nightly prerelease with changelog and binaries
Estimated code review effort
🎯 3 (Moderate) | ⏱️ ~20 minutes
Poem
🐰 I hopped through YAML, tidy and spry,
A reusable build beneath the sky.
Nightly I scurry, attach bins with glee,
Changelogs penned from v0.8.0 to be.
Hooray—CI hums, a release for thee!
🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
| Check name | Status | Explanation |
|---|---|---|
| Description Check | ✅ Passed | Check skipped - CodeRabbit’s high-level summary is enabled. |
| Title check | ✅ Passed | The pull request title 'Nightly builds' is partially related to the changeset, referring to one significant aspect (the nightly.yml workflow) but not capturing the main refactoring of extracting build logic into a reusable workflow. |
| Docstring Coverage | ✅ Passed | No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. |
✏️ Tip: You can configure your own custom pre-merge checks in the settings.
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands and usage tips.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 5
🤖 Fix all issues with AI agents
In @.github/workflows/build.yaml:
- Around line 12-27: The workflow currently builds but never uploads artifacts,
so downstream jobs (nightly release) find no binaries; add an upload step after
the "Build PlatformIO Project" step that uses actions/upload-artifact to upload
the produced binaries (include paths build/release/**, build/merged/** and any
*.bin outputs) so the nightly workflow can download them; reference the existing
step "Build PlatformIO Project" as the insertion point and ensure the upload
step names the artifact (e.g., firmware-binaries) and includes the outputs of
the post-build scripts rename_fw.py and merge_bin.py.
In @.github/workflows/ci-pio.yaml:
- Around line 3-6: The workflow is invalid because it lacks a top-level jobs:
block and references the wrong reusable workflow filename; add a jobs: entry
that defines a job (e.g., job name like build) which uses the reusable workflow
and correct the path to ./.github/workflows/build.yaml (replace uses:
./.github/workflows/build.yml with uses: ./.github/workflows/build.yaml) so the
file has a valid top-level jobs: -> build: -> uses: structure.
In @.github/workflows/nightly.yml:
- Around line 10-13: The reusable workflow reference under the wled_build job is
pointing to the wrong filename ("uses: ./.github/workflows/build.yml"); update
that uses entry to reference the actual file name ("build.yaml") so the
wled_build job uses the correct reusable workflow (i.e., change the uses value
from ./.github/workflows/build.yml to ./.github/workflows/build.yaml).
- Around line 1-16: The workflow’s "nightly" job needs explicit write permission
to create/update releases; update the workflow to grant the token "contents:
write" (either at the top-level permissions or specifically for the "nightly"
job) so the release-related steps can push changes — target the "nightly" job
name in your change and set permissions for GITHUB_TOKEN accordingly.
- Around line 32-33: Replace the unpinned GitHub Action reference
"andelf/nightly-release@main" with a pinned release tag or commit SHA to avoid
supply-chain risks; locate the workflow step using the exact string and change
it to a stable tag like "@v0.0.4", a major tag like "@v1", or a full commit SHA
so the action cannot change unexpectedly.
| steps: | ||
| - uses: actions/checkout@v4 | ||
| - uses: actions/cache@v4 | ||
| with: | ||
| path: | | ||
| ~/.cache/pip | ||
| ~/.platformio/.cache | ||
| key: ${{ runner.os }}-pio | ||
| - uses: actions/setup-python@v5 | ||
| with: | ||
| python-version: '3.11' | ||
| - name: Install PlatformIO Core | ||
| run: pip install --upgrade platformio | ||
|
|
||
| - name: Build PlatformIO Project | ||
| run: pio run |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🏁 Script executed:
find .github/workflows -type f -name "*.yaml" -o -name "*.yml"Repository: MoonModules/MoonLight
Length of output: 179
🏁 Script executed:
cat .github/workflows/build.yamlRepository: MoonModules/MoonLight
Length of output: 620
🏁 Script executed:
ls -la .github/workflows/Repository: MoonModules/MoonLight
Length of output: 415
🏁 Script executed:
cat .github/workflows/nightly.ymlRepository: MoonModules/MoonLight
Length of output: 1373
🏁 Script executed:
cat .github/workflows/ci-pio.yamlRepository: MoonModules/MoonLight
Length of output: 146
🏁 Script executed:
cat .github/workflows/ci.yamlRepository: MoonModules/MoonLight
Length of output: 645
🏁 Script executed:
# Check if there's a reference to what files PlatformIO actually outputs
rg "\.pio/build" .Repository: MoonModules/MoonLight
Length of output: 47
🏁 Script executed:
# Check the platformio.ini or similar config to understand the build output
find . -name "platformio.ini" -o -name ".platformio.ini" | head -5Repository: MoonModules/MoonLight
Length of output: 81
🏁 Script executed:
cat ./platformio.iniRepository: MoonModules/MoonLight
Length of output: 15425
🏁 Script executed:
# Check the actual project structure to understand build outputs
find . -type d -name "build" -o -type d -name ".pio" | head -10Repository: MoonModules/MoonLight
Length of output: 47
🏁 Script executed:
# Check if build.yml exists (different from build.yaml)
ls -la .github/workflows/ | grep buildRepository: MoonModules/MoonLight
Length of output: 124
🏁 Script executed:
# Check the nightly.yml more carefully for the exact workflow reference
grep -n "uses:" .github/workflows/nightly.ymlRepository: MoonModules/MoonLight
Length of output: 272
🏁 Script executed:
# Check if there's a build.yml file or if it's just named build.yaml
git ls-files | grep "build\."Repository: MoonModules/MoonLight
Length of output: 93
🏁 Script executed:
# Double-check the exact reference in ci-pio.yaml too
cat .github/workflows/ci-pio.yamlRepository: MoonModules/MoonLight
Length of output: 146
🏁 Script executed:
# Check what happens when PlatformIO builds - look for any build output references
rg "firmware" . -t py -t ini -A 2 -B 2Repository: MoonModules/MoonLight
Length of output: 92
🏁 Script executed:
# Check if there are any scripts that might define the output paths
ls -la scripts/Repository: MoonModules/MoonLight
Length of output: 577
🏁 Script executed:
cat scripts/rename_fw.pyRepository: MoonModules/MoonLight
Length of output: 2925
🏁 Script executed:
cat scripts/merge_bin.pyRepository: MoonModules/MoonLight
Length of output: 2539
🏁 Script executed:
# Check what files the nightly job expects to download
# Look for any file patterns mentioned
grep -A 5 "Download artifacts" .github/workflows/nightly.ymlRepository: MoonModules/MoonLight
Length of output: 230
🏁 Script executed:
# Check what the actual directory structure would be after pio run + scripts
# Look at what save_elf.py does to understand all outputs
cat scripts/save_elf.pyRepository: MoonModules/MoonLight
Length of output: 1026
🏁 Script executed:
# Check if there are any other workflow files that might be importing or calling build
rg "workflow_call\|reusable" .github/workflows/Repository: MoonModules/MoonLight
Length of output: 47
🏁 Script executed:
# Verify if GitHub can resolve build.yml to build.yaml by checking git history or any documentation
# For now, let's see all yaml/yml files in the workflows
find .github/workflows -type f \( -name "*.yaml" -o -name "*.yml" \) -exec basename {} \;Repository: MoonModules/MoonLight
Length of output: 107
🏁 Script executed:
# Check the platformio.ini to see what environment names are being used
# and understand the actual build directory structure that PlatformIO creates
grep "^\[env:" platformio.ini | head -20Repository: MoonModules/MoonLight
Length of output: 47
🏁 Script executed:
# Check if there's a .gitignore that might tell us what's normally generated
cat .gitignore | grep -E "build|\.pio"Repository: MoonModules/MoonLight
Length of output: 126
Nightly release will have no binaries without an artifact upload.
The reusable build job never uploads artifacts, but the nightly workflow later downloads artifacts and attaches *.bin files to a release. Add an upload step to make the binaries available to downstream jobs.
The post-build scripts (rename_fw.py, merge_bin.py) output binaries to build/release/ and build/merged/ directories, not .pio/build/.
🔧 Proposed fix (upload build outputs)
- name: Build PlatformIO Project
run: pio run
+ - name: Upload build artifacts
+ uses: actions/upload-artifact@v4
+ with:
+ name: platformio-build
+ path: build/**/*.bin📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| steps: | |
| - uses: actions/checkout@v4 | |
| - uses: actions/cache@v4 | |
| with: | |
| path: | | |
| ~/.cache/pip | |
| ~/.platformio/.cache | |
| key: ${{ runner.os }}-pio | |
| - uses: actions/setup-python@v5 | |
| with: | |
| python-version: '3.11' | |
| - name: Install PlatformIO Core | |
| run: pip install --upgrade platformio | |
| - name: Build PlatformIO Project | |
| run: pio run | |
| steps: | |
| - uses: actions/checkout@v4 | |
| - uses: actions/cache@v4 | |
| with: | |
| path: | | |
| ~/.cache/pip | |
| ~/.platformio/.cache | |
| key: ${{ runner.os }}-pio | |
| - uses: actions/setup-python@v5 | |
| with: | |
| python-version: '3.11' | |
| - name: Install PlatformIO Core | |
| run: pip install --upgrade platformio | |
| - name: Build PlatformIO Project | |
| run: pio run | |
| - name: Upload build artifacts | |
| uses: actions/upload-artifact@v4 | |
| with: | |
| name: platformio-build | |
| path: build/**/*.bin |
🤖 Prompt for AI Agents
In @.github/workflows/build.yaml around lines 12 - 27, The workflow currently
builds but never uploads artifacts, so downstream jobs (nightly release) find no
binaries; add an upload step after the "Build PlatformIO Project" step that uses
actions/upload-artifact to upload the produced binaries (include paths
build/release/**, build/merged/** and any *.bin outputs) so the nightly workflow
can download them; reference the existing step "Build PlatformIO Project" as the
insertion point and ensure the upload step names the artifact (e.g.,
firmware-binaries) and includes the outputs of the post-build scripts
rename_fw.py and merge_bin.py.
.github/workflows/ci-pio.yaml
Outdated
| on: [push] | ||
|
|
||
| jobs: | ||
| build: | ||
| runs-on: ubuntu-latest | ||
| build: | ||
| uses: ./.github/workflows/build.yml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Workflow is invalid: missing jobs: and wrong reusable workflow path.
Line 5 is parsed at the root, causing a syntax error, and it references build.yml even though the reusable workflow is build.yaml.
🛠️ Proposed fix
on: [push]
- build:
- uses: ./.github/workflows/build.yml
+jobs:
+ build:
+ uses: ./.github/workflows/build.yaml📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| on: [push] | |
| jobs: | |
| build: | |
| runs-on: ubuntu-latest | |
| build: | |
| uses: ./.github/workflows/build.yml | |
| on: [push] | |
| jobs: | |
| build: | |
| uses: ./.github/workflows/build.yaml |
🧰 Tools
🪛 actionlint (1.7.10)
4-4: could not parse as YAML: did not find expected key
(syntax-check)
🪛 YAMLlint (1.38.0)
[error] 5-5: syntax error: expected , but found ''
(syntax)
🤖 Prompt for AI Agents
In @.github/workflows/ci-pio.yaml around lines 3 - 6, The workflow is invalid
because it lacks a top-level jobs: block and references the wrong reusable
workflow filename; add a jobs: entry that defines a job (e.g., job name like
build) which uses the reusable workflow and correct the path to
./.github/workflows/build.yaml (replace uses: ./.github/workflows/build.yml with
uses: ./.github/workflows/build.yaml) so the file has a valid top-level jobs: ->
build: -> uses: structure.
|
|
||
| name: Deploy Nightly | ||
| on: | ||
| # This can be used to automatically publish nightlies at UTC nighttime | ||
| schedule: | ||
| - cron: '0 2 * * *' # run at 2 AM UTC | ||
| # This can be used to allow manually triggering nightlies from the web interface | ||
| workflow_dispatch: | ||
|
|
||
| jobs: | ||
| wled_build: | ||
| uses: ./.github/workflows/build.yml | ||
| nightly: | ||
| name: Deploy nightly | ||
| runs-on: ubuntu-latest | ||
| needs: wled_build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Release job likely needs explicit write permissions.
Creating/updating a release requires contents: write; the workflow currently relies on the default (read-only) token permissions.
🔧 Proposed fix
name: Deploy Nightly
on:
schedule:
- cron: '0 2 * * *' # run at 2 AM UTC
workflow_dispatch:
+
+permissions:
+ contents: write📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| name: Deploy Nightly | |
| on: | |
| # This can be used to automatically publish nightlies at UTC nighttime | |
| schedule: | |
| - cron: '0 2 * * *' # run at 2 AM UTC | |
| # This can be used to allow manually triggering nightlies from the web interface | |
| workflow_dispatch: | |
| jobs: | |
| wled_build: | |
| uses: ./.github/workflows/build.yml | |
| nightly: | |
| name: Deploy nightly | |
| runs-on: ubuntu-latest | |
| needs: wled_build | |
| name: Deploy Nightly | |
| on: | |
| # This can be used to automatically publish nightlies at UTC nighttime | |
| schedule: | |
| - cron: '0 2 * * *' # run at 2 AM UTC | |
| # This can be used to allow manually triggering nightlies from the web interface | |
| workflow_dispatch: | |
| permissions: | |
| contents: write | |
| jobs: | |
| wled_build: | |
| uses: ./.github/workflows/build.yml | |
| nightly: | |
| name: Deploy nightly | |
| runs-on: ubuntu-latest | |
| needs: wled_build |
🧰 Tools
🪛 actionlint (1.7.10)
12-12: could not read reusable workflow file for "./.github/workflows/build.yml": open /home/jailuser/git/.github/workflows/build.yml: no such file or directory
(workflow-call)
🤖 Prompt for AI Agents
In @.github/workflows/nightly.yml around lines 1 - 16, The workflow’s "nightly"
job needs explicit write permission to create/update releases; update the
workflow to grant the token "contents: write" (either at the top-level
permissions or specifically for the "nightly" job) so the release-related steps
can push changes — target the "nightly" job name in your change and set
permissions for GITHUB_TOKEN accordingly.
| jobs: | ||
| wled_build: | ||
| uses: ./.github/workflows/build.yml | ||
| nightly: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reusable workflow path is wrong.
build.yml doesn’t exist; the file is build.yaml. This job won’t start until the path is corrected.
🛠️ Proposed fix
wled_build:
- uses: ./.github/workflows/build.yml
+ uses: ./.github/workflows/build.yaml📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| jobs: | |
| wled_build: | |
| uses: ./.github/workflows/build.yml | |
| nightly: | |
| jobs: | |
| wled_build: | |
| uses: ./.github/workflows/build.yaml | |
| nightly: |
🧰 Tools
🪛 actionlint (1.7.10)
12-12: could not read reusable workflow file for "./.github/workflows/build.yml": open /home/jailuser/git/.github/workflows/build.yml: no such file or directory
(workflow-call)
🤖 Prompt for AI Agents
In @.github/workflows/nightly.yml around lines 10 - 13, The reusable workflow
reference under the wled_build job is pointing to the wrong filename ("uses:
./.github/workflows/build.yml"); update that uses entry to reference the actual
file name ("build.yaml") so the wled_build job uses the correct reusable
workflow (i.e., change the uses value from ./.github/workflows/build.yml to
./.github/workflows/build.yaml).
| - name: Update Nightly Release | ||
| uses: andelf/nightly-release@main |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/nightly.yml | sed -n '30,35p'Repository: MoonModules/MoonLight
Length of output: 388
🌐 Web query:
andelf/nightly-release GitHub action releases tags versions
💡 Result:
I couldn’t find a publicly accessible GitHub repository page (or its Releases/Tags) for andelf/nightly-release via web search right now—this typically means the repo is private, renamed, deleted, or otherwise not indexed.
If you do have access, here’s how to determine the Action’s available release versions/tags:
- On GitHub UI
- Check the repo’s Releases page (lists released versions like
v1.2.3) - Check the repo’s Tags page (lists all tags, including moving tags like
v1)
- Check the repo’s Releases page (lists released versions like
- Via Git CLI (no UI needed)
git ls-remote --tags https://github.com/andelf/nightly-release.git
- Via GitHub CLI
gh release list -R andelf/nightly-release
For Actions versioning best practice: publish immutable semver tags (e.g. v1.2.3) and optionally maintain moving major/minor tags (e.g. v1, v1.2) so users can pin safely. GitHub recommends semantic version tags and keeping major/minor tags updated to the latest compatible release. [1] [2]
Sources
[1] https://docs.github.com/en/actions/how-tos/create-and-publish-actions/using-immutable-releases-and-tags-to-manage-your-actions-releases
[2] https://docs.github.com/actions/creating-actions/releasing-and-maintaining-actions
🏁 Script executed:
git ls-remote --tags https://github.com/andelf/nightly-release.git | head -20Repository: MoonModules/MoonLight
Length of output: 409
Pin andelf/nightly-release to a specific version tag.
Using @main is a supply-chain risk; the action can be updated at any time without notice. Pin to a release tag like @v0.0.4 or @v1, or a full commit SHA.
🔒 Proposed fix (example)
- - name: Update Nightly Release
- uses: andelf/nightly-release@main
+ - name: Update Nightly Release
+ uses: andelf/nightly-release@v0.0.4📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Update Nightly Release | |
| uses: andelf/nightly-release@main | |
| - name: Update Nightly Release | |
| uses: andelf/nightly-release@v0.0.4 |
🤖 Prompt for AI Agents
In @.github/workflows/nightly.yml around lines 32 - 33, Replace the unpinned
GitHub Action reference "andelf/nightly-release@main" with a pinned release tag
or commit SHA to avoid supply-chain risks; locate the workflow step using the
exact string and change it to a stable tag like "@v0.0.4", a major tag like
"@v1", or a full commit SHA so the action cannot change unexpectedly.
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.