1 #708
Open
1 #708
+110
−2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Reviewer's GuideAdds a new GitHub Actions workflow to build a Flatpak snapshot for the project on a dedicated branch and deploy the resulting Flatpak repository to GitHub Pages. Sequence diagram for Flatpak snapshot CI/CD pipelinesequenceDiagram
actor Developer
participant GitHub
participant Workflow as FlatpakSnapshotWorkflow
participant Runner as GitHubActionsRunner
participant FlatpakBuilder
participant Pages as GitHubPages
Developer->>GitHub: Push to branch flatpak-snapshot
GitHub-->>Workflow: Trigger workflow on push or manual dispatch
Workflow->>Runner: Start build-and-deploy job
Runner->>GitHub: Checkout repository
Runner->>Runner: Install Flatpak and dependencies
Runner->>Runner: Install GNOME SDK and Platform runtimes
Runner->>Runner: Compute VERSION from git short hash and set env
Runner->>FlatpakBuilder: Run flatpak-builder to build Flatpak into build-dir
FlatpakBuilder-->>Runner: Build output in build-dir
Runner->>FlatpakBuilder: Export Flatpak repo to repo directory
FlatpakBuilder-->>Runner: Flatpak repository in repo
Runner->>GitHub: Commit and push repo directory to gh-pages branch
GitHub-->>Pages: Update published site with new Flatpak repo
Developer-->>Pages: Access updated Flatpak snapshot via GitHub Pages
Flow diagram for Flatpak snapshot build-and-deploy jobflowchart TD
A[Start build-and-deploy job] --> B[Checkout repository actions/checkout@v4]
B --> C[Install Flatpak and dependencies via apt]
C --> D[Install GNOME SDK and Platform runtimes from Flathub]
D --> E[Set snapshot version from git rev-parse --short HEAD and export VERSION env]
E --> F[Build Flatpak with flatpak-builder using iptux.flatpak.yaml into build-dir]
F --> G[Export Flatpak repository from build-dir to repo with collection id io.github.iptux]
G --> H[Deploy repo directory to gh-pages branch using actions-gh-pages]
H --> I[End job with updated Flatpak snapshot on GitHub Pages]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 2 issues, and left some high level feedback:
- Consider pinning the GitHub Actions you use (e.g.,
actions/checkout@v4,peaceiris/actions-gh-pages@v4) to specific commit SHAs to avoid unexpected behavior changes when those actions are updated. - The workflow installs Flatpak and the GNOME SDK from scratch on every run; you might want to introduce caching (e.g., for
flatpak-builderdownloads or thebuild-dir/runtime) or use a dedicated Flatpak setup action to reduce build time and resource usage.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Consider pinning the GitHub Actions you use (e.g., `actions/checkout@v4`, `peaceiris/actions-gh-pages@v4`) to specific commit SHAs to avoid unexpected behavior changes when those actions are updated.
- The workflow installs Flatpak and the GNOME SDK from scratch on every run; you might want to introduce caching (e.g., for `flatpak-builder` downloads or the `build-dir`/runtime) or use a dedicated Flatpak setup action to reduce build time and resource usage.
## Individual Comments
### Comment 1
<location> `.github/workflows/flatpak-snapshot.yml:16-17` </location>
<code_context>
+ contents: write
+ steps:
+ # 1. Checkout repo
+ - name: Checkout
+ uses: actions/checkout@v4
+
+ # 2. Set up Flatpak
</code_context>
<issue_to_address>
**🚨 suggestion (security):** Consider pinning GitHub Actions to specific commit SHAs for supply-chain security
Floating tags like `@v4` can change over time and introduce supply-chain risk. Please pin `actions/checkout` (and other third-party actions in this workflow) to a specific commit SHA, with an inline comment noting the version for traceability.
Suggested implementation:
```
# 1. Checkout repo
- name: Checkout
# v4.2.2
uses: actions/checkout@9bb56186c3b09b4f86b1c65136769dd318469633
```
If there are other third-party actions used elsewhere in this workflow file (or in other workflow files), they should also be updated to use commit SHA pins with inline comments indicating the tagged version (e.g., `# vX.Y.Z`) for consistency and supply-chain security.
</issue_to_address>
### Comment 2
<location> `.github/workflows/flatpak-snapshot.yml:40-42` </location>
<code_context>
+ echo "Snapshot version set to ${VERSION}"
+
+ # 5. Build Flatpak
+ - name: Build Flatpak
+ run: |
+ flatpak-builder --force-clean build-dir iptux.flatpak.yaml
+
+ # 6. Export repository to repo/
</code_context>
<issue_to_address>
**suggestion:** Consider wiring the computed VERSION into the Flatpak build to keep metadata consistent
Right now `VERSION` (from the Git hash) is only used in the commit message. If `iptux.flatpak.yaml` defines a version or relies on `--env`/`--default-branch`, consider passing `${{ env.VERSION }}` into the Flatpak build so the Flatpak metadata matches the snapshot version instead of just the GitHub Pages commit.
Suggested implementation:
```
# 5. Build Flatpak
- name: Build Flatpak
env:
VERSION: ${{ env.VERSION }}
run: |
flatpak-builder --force-clean build-dir iptux.flatpak.yaml
```
If `iptux.flatpak.yaml` does not yet reference the `VERSION` environment variable, you may also want to:
1. Add `${VERSION}` in the manifest’s `app-id`, `branch`, or `metadata` (e.g. `version: ${VERSION}`) as appropriate.
2. Optionally, if you prefer using Flatpak’s CLI flags instead of env substitution, you could additionally change the run command to include flags like `--default-branch=${VERSION}` or `--env=VERSION=${VERSION}`, depending on how your manifest is structured.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Comment on lines
+16
to
+17
| - name: Checkout | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
🚨 suggestion (security): Consider pinning GitHub Actions to specific commit SHAs for supply-chain security
Floating tags like @v4 can change over time and introduce supply-chain risk. Please pin actions/checkout (and other third-party actions in this workflow) to a specific commit SHA, with an inline comment noting the version for traceability.
Suggested implementation:
# 1. Checkout repo
- name: Checkout
# v4.2.2
uses: actions/checkout@9bb56186c3b09b4f86b1c65136769dd318469633
If there are other third-party actions used elsewhere in this workflow file (or in other workflow files), they should also be updated to use commit SHA pins with inline comments indicating the tagged version (e.g., # vX.Y.Z) for consistency and supply-chain security.
Comment on lines
40
to
42
| - name: Build Flatpak | ||
| run: | | ||
| flatpak-builder --force-clean build-dir iptux.flatpak.yaml |
There was a problem hiding this comment.
suggestion: Consider wiring the computed VERSION into the Flatpak build to keep metadata consistent
Right now VERSION (from the Git hash) is only used in the commit message. If iptux.flatpak.yaml defines a version or relies on --env/--default-branch, consider passing ${{ env.VERSION }} into the Flatpak build so the Flatpak metadata matches the snapshot version instead of just the GitHub Pages commit.
Suggested implementation:
# 5. Build Flatpak
- name: Build Flatpak
env:
VERSION: ${{ env.VERSION }}
run: |
flatpak-builder --force-clean build-dir iptux.flatpak.yaml
If iptux.flatpak.yaml does not yet reference the VERSION environment variable, you may also want to:
- Add
${VERSION}in the manifest’sapp-id,branch, ormetadata(e.g.version: ${VERSION}) as appropriate. - Optionally, if you prefer using Flatpak’s CLI flags instead of env substitution, you could additionally change the run command to include flags like
--default-branch=${VERSION}or--env=VERSION=${VERSION}, depending on how your manifest is structured.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #708 +/- ##
==========================================
- Coverage 52.01% 51.99% -0.03%
==========================================
Files 64 64
Lines 8599 8601 +2
==========================================
- Hits 4473 4472 -1
- Misses 4126 4129 +3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary by Sourcery
Add a GitHub Actions workflow to build and publish Flatpak snapshot builds from a dedicated branch to GitHub Pages.
CI:
Deployment: