[V3-Linux] Support for deb,rpm,arch linux packager packaging #3909
Conversation
|
Caution Review failedThe pull request is closed. WalkthroughThe pull request introduces significant updates to the project's changelog, detailing enhancements across various categories such as Added, Changed, and Fixed. New commands for Linux packaging and enhanced documentation are included. Additionally, several new shell scripts and a template for NFPM packaging are introduced. Modifications to the package manager implementations streamline package checks and installation commands. The Wails CLI is updated with a new subcommand for package generation, and the Changes
Possibly related PRs
📜 Recent review detailsConfiguration used: .coderabbit.yaml ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Outside diff range and nitpick comments (16)
v3/internal/commands/updatable_build_assets/nfpm.yaml.tmpl (1)
1-20: Consider enhancing the packaging configuration for better distribution supportTo improve the Linux packaging strategy, consider adding:
- Distribution-specific configuration overrides
- Package dependencies management
- Pre/post installation scripts
- Package conflicts and replaces declarations
Example structure for enhanced packaging:
# Example of additional configurations to consider dependencies: - webkit2gtk-4.0 - gtk3 overrides: deb: section: "utils" depends: - libgtk-3-0 rpm: group: "Applications/System" requires: - gtk3 scripts: preinstall: | # Add preinstall steps postinstall: | # Add postinstall steps conflicts: - old-package-name replaces: - legacy-package-namev3/internal/commands/updatable_build_assets/nfpm/nfpm.yaml.tmpl (3)
1-5: Improve header documentation clarityThe modeline reference seems out of context and might confuse users. Consider replacing it with more relevant information about the template's purpose and usage.
-# The lines below are called `modelines`. See `:help modeline` +# This template configures package metadata and contents for Linux package generation. +# For detailed configuration options, visit: +# https://nfpm.goreleaser.com/configuration/
19-23: Review installation paths and permissionsThe current configuration has several potential issues:
/usr/local/binmight not be the preferred location for all distributions (e.g., Debian packages typically use/usr/bin).- The icon path assumes a specific hierarchy and PNG format.
- File permissions are not explicitly set.
Consider making the paths configurable and adding mode/permissions:
contents: - src: "./bin/{{.BinaryName}}" - dst: "/usr/local/bin/{{.BinaryName}}" + dst: "{{.BinDir}}/{{.BinaryName}}" + mode: 0755 - src: "./build/appicon.png" - dst: "/usr/share/icons/hicolor/128x128/apps/{{.BinaryName}}.png" + dst: "{{.IconDir}}/{{.BinaryName}}.png" + mode: 0644
25-44: Enhance optional configurations documentation and defaultsThe commented sections could benefit from:
- Documentation explaining when each option should be used.
- Default dependencies for GUI applications (webkit2gtk, gtk3).
- Flexible script paths using template variables.
Consider adding these defaults:
# depends: -# - foo -# - bar +# - webkit2gtk-4.0 +# - gtk3 +# - libayatana-appindicator3-1 # For system tray support # scripts: -# preinstall: ./build/nfpm/scripts/preinstall.sh +# preinstall: "{{.ScriptsDir}}/preinstall.sh"Also, consider adding comments explaining when each option should be used:
# Package Relations: # - depends: Required dependencies for the application to run # - recommends: Optional but strongly suggested packages # - suggests: Optional packages that enhance functionality # - conflicts: Packages that cannot be installed simultaneouslyv3/internal/doctor/packagemanager/pm.go (2)
10-10: Good addition of InstallCheck callback.The new
InstallCheckfunction provides a flexible way to implement custom installation verification, which is particularly valuable for optional dependencies like nFPM. This improves the robustness of the package management system.Consider adding:
- Documentation about expected behavior of the callback
- Error handling guidelines for implementers
- Timeout handling recommendations for long-running checks
9-10: Consider adding validation for InstallCommand and InstallCheck.Since these fields are critical for package management operations, consider adding validation when Package instances are created.
type Package struct { Name string Version string InstallCommand string InstallCheck func() bool SystemPackage bool Library bool Optional bool } + +// Validate ensures the Package is properly configured +func (p *Package) Validate() error { + if p.InstallCommand == "" { + return fmt.Errorf("package %s: InstallCommand cannot be empty", p.Name) + } + if p.InstallCheck == nil { + return fmt.Errorf("package %s: InstallCheck cannot be nil", p.Name) + } + return nil +}v3/internal/doctor/packagemanager/apt.go (1)
43-45: Consider pinning the nfpm version for stabilityWhile using
@latestensures you get the newest features, it may lead to unexpected behavior if breaking changes are introduced. Consider pinning to a specific version for better stability and reproducibility.- {Name: "nfpm", SystemPackage: false, InstallCheck: isNfpmInstalled, InstallCommand: "go install github.com/goreleaser/nfpm/v2/cmd/nfpm@latest", Optional: true}, + {Name: "nfpm", SystemPackage: false, InstallCheck: isNfpmInstalled, InstallCommand: "go install github.com/goreleaser/nfpm/v2/cmd/nfpm@v2.35.3", Optional: true},v3/internal/doctor/packagemanager/eopkg.go (2)
83-83: LGTM! Consider adding command validationThe direct return of InstallCommand is clean and appropriate. For future enhancements, consider adding command validation to ensure the InstallCommand is properly formatted and secure.
Consider implementing:
- Command string validation
- Command execution permission checks
- Fallback commands for failed installations
Line range hint
44-83: Consider enhancing error handling for package operationsThe implementation successfully adds nfpm support, but consider these architectural improvements:
- Add error logging for failed package operations
- Implement retry mechanisms for network-dependent operations
- Add telemetry for package installation success rates
These enhancements would improve reliability and maintainability of the package management system.
v3/internal/commands/build_assets/Taskfile.linux.yml (3)
31-34: Enhance the nfpm requirement commentThe comment could be more informative about the nfpm requirement.
Consider updating the comment to be more descriptive:
- # Requires nfpm to be installed + # Optional tasks below require nfpm (https://nfpm.goreleaser.com/) to be installed: # - task: create:deb # - task: create:rpm # - task: create:aur
55-81: Enhance task summaries for clarityThe task summaries could be more descriptive about what they do.
Consider updating the summaries to be more specific:
- summary: Creates a deb package + summary: Builds the production application and creates a Debian (.deb) package - summary: Creates a rpm package + summary: Builds the production application and creates a RedHat (.rpm) package - summary: Creates a arch linux packager package + summary: Builds the production application and creates an Arch Linux (.pkg.tar.zst) package
Line range hint
1-96: Consider adding version management for packagesThe current implementation doesn't specify how package versions are managed. This could lead to inconsistencies between different package formats.
Consider:
- Adding a common version variable at the task level
- Passing this version to nfpm configuration
- Implementing a version naming scheme that complies with all package format requirements (deb, rpm, and arch)
Example structure:
vars: PKG_VERSION: '{{.VERSION | default "0.1.0"}}' PKG_RELEASE: '{{.RELEASE | default "1"}}'🧰 Tools
🪛 yamllint (1.29.0-1)
[error] 84-84: trailing spaces
(trailing-spaces)
[error] 89-89: trailing spaces
(trailing-spaces)
[error] 94-94: trailing spaces
(trailing-spaces)
v3/internal/doctor/packagemanager/nixpkgs.go (1)
Line range hint
58-151: Well-structured integration of optional package supportThe changes demonstrate good architectural decisions:
- Clear separation between system and non-system packages
- Flexible verification through InstallCheck callbacks
- Extensible design that can accommodate future optional packages
- Consistent integration with existing package manager framework
This provides a solid foundation for the Linux packaging support being added in this PR.
v3/internal/doctor/doctor.go (1)
Remove redundant buildinfo.Get() call
The code in
doctor.gohas a redundant call tobuildinfo.Get()where the result is explicitly ignored. Looking at the implementation:
buildinfo.Get()internally usesdebug.ReadBuildInfo()to get build information- The same code later directly uses
debug.ReadBuildInfo()twice for the same purpose- The ignored
buildinfo.Get()result provides no additional valueRemove lines 22-26 as they serve no purpose:
get, err := buildinfo.Get() if err != nil { return err } _ = get🔗 Analysis chain
Line range hint
22-26: Remove or utilize unused buildinfo.Get() callThe code retrieves build information twice:
- Using
buildinfo.Get()but explicitly ignoring the result- Later using
debug.ReadBuildInfo()directlyThis appears redundant and could indicate incomplete refactoring.
Let's verify the intended usage:
Let me gather more information about the usage of
debug.ReadBuildInfo()in the doctor package to understand the redundancy better.
Let me check the buildinfo package implementation to understand its relationship with
debug.ReadBuildInfo().🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check how buildinfo.Get() is used across the codebase rg -A 5 "buildinfo\.Get\(\)" # Check if there are any recent changes to buildinfo package ast-grep --pattern 'package buildinfo'Length of output: 1123
Script:
#!/bin/bash # Check for debug.ReadBuildInfo usage in doctor.go rg -A 5 "debug\.ReadBuildInfo\(\)" v3/internal/doctor/doctor.go # Look at the full doctor.go implementation to understand the context cat v3/internal/doctor/doctor.goLength of output: 6684
Script:
#!/bin/bash # Check the implementation of buildinfo.Get() cat v3/internal/buildinfo/buildinfo.goLength of output: 787
mkdocs-website/docs/en/changelog.md (2)
Line range hint
21-38: Consider adding more details about the Linux packaging features.While the entry mentions the addition of Linux packaging support, it would be beneficial to include:
- The specific task names added (linux:create:deb, linux:create:rpm, etc.)
- Any dependencies required (e.g., nFPM)
Consider expanding the entry like this:
-Support of linux packaging of deb,rpm, and arch linux packager builds by @atterpac in [#3909](https://github.com/wailsapp/wails/3909) +Support of Linux packaging (deb, rpm, and arch) using nFPM by @atterpac in [#3909](https://github.com/wailsapp/wails/3909) +- Added tasks: + - linux:create:deb: Builds and packages for Debian + - linux:create:rpm: Builds and packages for RedHat + - linux:create:aur: Builds and packages for Arch Linux + - linux:generate:deb/rpm/aur: Generates packages from existing builds
Line range hint
93-94: Fix version entry format.The version entry for v3.0.0-alpha.6 is missing a description of changes. Even for minor releases with only module fixes, it's better to provide more context.
Consider expanding the entry like this:
## v3.0.0-alpha.6 - 2024-07-30 ### Fixed -Module issues +- Fixed module dependency resolution issues affecting package imports
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (18)
mkdocs-website/docs/en/changelog.md(1 hunks)v3/internal/commands/build_assets/Taskfile.linux.yml(2 hunks)v3/internal/commands/updatable_build_assets/nfpm.yaml.tmpl(1 hunks)v3/internal/commands/updatable_build_assets/nfpm/nfpm.yaml.tmpl(1 hunks)v3/internal/commands/updatable_build_assets/nfpm/scripts/postinstall.sh(1 hunks)v3/internal/commands/updatable_build_assets/nfpm/scripts/postremove.sh(1 hunks)v3/internal/commands/updatable_build_assets/nfpm/scripts/preinstall.sh(1 hunks)v3/internal/commands/updatable_build_assets/nfpm/scripts/preremove.sh(1 hunks)v3/internal/doctor/doctor.go(1 hunks)v3/internal/doctor/packagemanager/apt.go(4 hunks)v3/internal/doctor/packagemanager/dnf.go(3 hunks)v3/internal/doctor/packagemanager/emerge.go(2 hunks)v3/internal/doctor/packagemanager/eopkg.go(3 hunks)v3/internal/doctor/packagemanager/nixpkgs.go(3 hunks)v3/internal/doctor/packagemanager/packagemanager.go(2 hunks)v3/internal/doctor/packagemanager/pacman.go(3 hunks)v3/internal/doctor/packagemanager/pm.go(1 hunks)v3/internal/doctor/packagemanager/zypper.go(3 hunks)
✅ Files skipped from review due to trivial changes (4)
- v3/internal/commands/updatable_build_assets/nfpm/scripts/postinstall.sh
- v3/internal/commands/updatable_build_assets/nfpm/scripts/postremove.sh
- v3/internal/commands/updatable_build_assets/nfpm/scripts/preinstall.sh
- v3/internal/commands/updatable_build_assets/nfpm/scripts/preremove.sh
🧰 Additional context used
🪛 yamllint (1.29.0-1)
v3/internal/commands/build_assets/Taskfile.linux.yml
[error] 84-84: trailing spaces
(trailing-spaces)
[error] 89-89: trailing spaces
(trailing-spaces)
[error] 94-94: trailing spaces
(trailing-spaces)
🔇 Additional comments (25)
v3/internal/commands/updatable_build_assets/nfpm/nfpm.yaml.tmpl (1)
6-17: 🛠️ Refactor suggestion
Review package metadata configuration
Several potential issues in the metadata configuration:
- The mix of environment variables and template variables might cause confusion.
- The hardcoded homepage URL "https://wails.io" should be templated.
- Consider making the release number configurable.
Let's verify the template variables are properly defined:
Suggested improvements:
-homepage: "https://wails.io"
+homepage: "{{.Homepage}}"
-release: "1"
+release: "{{.Release}}"v3/internal/doctor/packagemanager/pm.go (1)
9-10: Verify the impact of InstallCommand simplification.
The change from map[string]string to string for InstallCommand simplifies the API but might reduce flexibility. Ensure this change doesn't break scenarios where different install commands were needed for different package manager states or environments.
Consider documenting the rationale for this simplification in the package documentation to help maintainers understand the design decision.
✅ Verification successful
Let me gather more information about the v3 implementation to understand the complete picture.
The InstallCommand simplification is a valid architectural improvement
The change from map[string]string to string in v3 is well-justified based on the implementation evidence:
-
All package managers (apt, dnf, pacman, etc.) follow a consistent pattern where:
- For system packages: They generate a standard command (e.g., "sudo apt install pkg")
- For non-system packages: They directly use pkg.InstallCommand
-
The old v2 approach of using map[string]string was only used in specific cases (like Docker installation guides), which has been moved to a more appropriate implementation in v3.
The addition of InstallCheck func() bool complements this simplification by providing a more flexible way to verify installations, especially for complex cases that previously relied on different commands.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if there are any package managers using multiple install commands
# Search for any package manager implementations that might be affected
rg -A 5 "InstallCommand.*map\[string\]string"
# Check package manager implementations for multiple command variations
ast-grep --pattern 'func ($pm *$_) InstallCommand($pkg *Package) string {
$$$
return $cmd
}'
Length of output: 1016
Script:
#!/bin/bash
# Check v3 package manager implementations
rg -A 10 "type.*Package.*struct" v3/internal/doctor/packagemanager/
rg -A 10 "InstallCommand.*string" v3/internal/doctor/packagemanager/
Length of output: 7980
v3/internal/doctor/packagemanager/apt.go (3)
60-63: LGTM! Clean implementation of non-system package checks
The logic correctly handles both system and non-system packages, with proper fallback behavior.
73-74: LGTM! Appropriate handling of non-system package availability
The change correctly assumes non-system packages are always available since they're installed through their own mechanisms.
87-88: LGTM! Verify the install command works across environments
The implementation correctly handles both system and non-system package installation commands.
Let's verify that the install command works in different environments:
✅ Verification successful
Implementation is consistent across package managers and environments
The code analysis shows that:
- The InstallCommand implementation is consistent across all package managers (apt, dnf, pacman, etc.)
- For non-system packages like nfpm, it correctly returns the direct InstallCommand (
go install github.com/goreleaser/nfpm/v2/cmd/nfpm@latest) - For system packages, it uses the appropriate package manager command (e.g.,
sudo apt install,sudo dnf install, etc.) - The change from v2 to v3 simplified the InstallCommand handling by removing the osid mapping, making it more maintainable
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that the go install command works across different Linux distributions
# Check if go is available in PATH
if ! command -v go &> /dev/null; then
echo "Error: go is not installed"
exit 1
fi
# Check minimum Go version required for nfpm
go version | awk '{
split($3, v, "go")
if (v[2] < "1.20") {
print "Warning: nfpm requires Go 1.20 or later"
exit 1
}
}'
Length of output: 87
Script:
#!/bin/bash
# Let's analyze the actual implementation to verify the install command handling
# Find the relevant package manager implementations
fd -e go -x rg -l "type.*Package.*Manager" {}
# Check the InstallCommand implementations
rg -A 5 "func.*InstallCommand"
# Look for test cases related to InstallCommand
rg -A 5 "Test.*InstallCommand"
# Find where InstallCommand is being used
ast-grep --pattern 'InstallCommand'
Length of output: 8832
v3/internal/doctor/packagemanager/pacman.go (3)
57-60: LGTM! Clean implementation of non-system package checks.
The logic for handling non-system packages is well-structured and properly handles optional InstallCheck functions.
112-112: LGTM! Simplified InstallCommand handling.
The direct return of InstallCommand for non-system packages is a cleaner approach.
44-46: Verify the referenced isNfpmInstalled function exists.
The package entry references isNfpmInstalled function but it's not visible in this file.
✅ Verification successful
The isNfpmInstalled function is properly defined and referenced
The function is defined in packagemanager.go and correctly implements a path-based check for the nfpm binary, following the same pattern used for other package checks in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for isNfpmInstalled function definition
rg -l "func.*isNfpmInstalled"
Length of output: 83
Script:
#!/bin/bash
# Get the implementation of isNfpmInstalled function
rg "func.*isNfpmInstalled" -A 10 v3/internal/doctor/packagemanager/packagemanager.go
Length of output: 170
v3/internal/doctor/packagemanager/eopkg.go (2)
57-60: LGTM! Clean implementation of non-system package checks
The changes improve code clarity by:
- Using early returns for better flow control
- Properly handling optional InstallCheck functions
- Maintaining clear separation between system and non-system packages
44-46: Verify the existence of isNfpmInstalled function
The configuration for nfpm looks good, but we need to ensure the referenced isNfpmInstalled function exists and is accessible.
✅ Verification successful
The isNfpmInstalled function exists and is properly referenced
The isNfpmInstalled function is defined in v3/internal/doctor/packagemanager/packagemanager.go and is consistently used across all package manager implementations (apt, dnf, eopkg, emerge, nixpkgs, pacman, zypper) for nfpm package configuration.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for isNfpmInstalled function definition
rg -p "func.*isNfpmInstalled"
# Search for any references to isNfpmInstalled
rg "isNfpmInstalled"
Length of output: 1681
v3/internal/doctor/packagemanager/emerge.go (2)
112-112: LGTM! Clean simplification of InstallCommand logic
The direct return of pkg.InstallCommand for non-system packages is a good simplification that maintains the correct behavior.
44-46: Consider version pinning strategy for nfpm installation
While the configuration looks good overall, installing the latest version could lead to compatibility issues or inconsistent builds across different environments. Consider:
- Pinning to a specific version for reproducible builds
- Verifying the
isNfpmInstalledfunction implementation
Let's verify the isNfpmInstalled function implementation:
Consider adding version constraints in the installation command:
-InstallCommand: "go install github.com/goreleaser/nfpm/v2/cmd/nfpm@latest"
+InstallCommand: "go install github.com/goreleaser/nfpm/v2/cmd/nfpm@v2.30.1"✅ Verification successful
Using latest tag for nfpm installation is appropriate
The implementation is correct and well-designed:
- The
isNfpmInstalledfunction properly checks for the binary usingLookPath - The package is correctly marked as optional, which aligns with its role as a supplementary tool
- Using
@latestis actually appropriate here because:- nfpm is an optional development tool, not a core dependency
- Version is checked at runtime via
nfpmVersion()function - Being a doctor/setup utility, it should help developers get the most recent stable version
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for isNfpmInstalled function definition
rg -A 5 "func isNfpmInstalled"
Length of output: 324
Script:
#!/bin/bash
# Let's check if there are any version constraints or specific versions used in other parts of the codebase
rg -i "nfpm.*@v\d"
# Also check for any version-related configuration or constants
rg -i "nfpm.*version"
# Check if nfpm is used as a dependency in go.mod
grep -A 5 "goreleaser/nfpm" go.mod || true
Length of output: 376
v3/internal/doctor/packagemanager/dnf.go (3)
59-62: LGTM! Clean implementation of custom install checks.
The changes improve code readability and add necessary support for custom installation verification.
112-112: LGTM! Simplified command handling.
The direct return of InstallCommand for non-system packages is clean and appropriate.
46-48: Verify the package name pattern and installation approach.
A few concerns about the nFPM package configuration:
- The wildcard in "nfpm*" seems unusual - verify if this pattern is intentional
- Using @latest for installation could lead to version inconsistency issues across different environments
Consider pinning to a specific version instead of @latest for better reproducibility:
-{Name: "nfpm", SystemPackage: false, InstallCheck: isNfpmInstalled, InstallCommand: "go install github.com/goreleaser/nfpm/v2/cmd/nfpm@latest", Optional: true},
+{Name: "nfpm", SystemPackage: false, InstallCheck: isNfpmInstalled, InstallCommand: "go install github.com/goreleaser/nfpm/v2/cmd/nfpm@v2.30.1", Optional: true},✅ Verification successful
The nFPM configuration is consistent across package managers
The wildcard pattern "nfpm*" is intentionally used to match the package name, and the implementation is consistent with how nFPM is configured across all package managers (apt, dnf, pacman, etc.). The @latest version tag is also consistently used across all package managers, suggesting this is a deliberate design choice for handling this optional Go-based dependency.
The implementation is verified through:
- The isNfpmInstalled function correctly checks for the binary presence
- The package configuration is uniform across all package managers
- The wildcard pattern is used specifically for nFPM and appears to be intentional
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the wildcard pattern is used consistently across other package managers
# Check for similar wildcard patterns in other package manager files
rg -l "nfpm\*" v3/internal/doctor/packagemanager/
# Verify the isNfpmInstalled function implementation
ast-grep --pattern 'func isNfpmInstalled() bool {
$$$
}'
Length of output: 461
Script:
#!/bin/bash
# Let's check how the package patterns are used in other package managers
rg -A 3 -B 3 '"[^"]+\*":\s+\[' v3/internal/doctor/packagemanager/
# Check if there are any version constraints for other Go tools
rg '@[a-z0-9.]+' v3/internal/doctor/packagemanager/
# Check if nfpm is used in other parts of the codebase
rg -l 'nfpm' --type go
Length of output: 2531
v3/internal/doctor/packagemanager/zypper.go (3)
60-63: LGTM! Clean and robust implementation.
The updated logic for non-system packages is well-structured and properly handles custom installation checks.
110-110: LGTM! Clean simplification of the install command logic.
The direct return of InstallCommand for non-system packages is a clean improvement.
47-49: Consider pinning the nfpm version for better reproducibility.
The addition of nfpm package support aligns well with the PR objectives. However, using @latest in the install command could lead to inconsistent builds across different environments.
Consider pinning to a specific version:
-InstallCommand: "go install github.com/goreleaser/nfpm/v2/cmd/nfpm@latest"
+InstallCommand: "go install github.com/goreleaser/nfpm/v2/cmd/nfpm@v2.30.1"Let's verify the existence and implementation of the isNfpmInstalled function:
✅ Verification successful
The isNfpmInstalled function is properly implemented and referenced
The verification confirms that isNfpmInstalled is correctly implemented in packagemanager.go using exec.LookPath to check for the nfpm binary in the system's PATH, which is the standard way to verify binary availability.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for isNfpmInstalled function definition
ast-grep --pattern 'func isNfpmInstalled() bool {
$$$
}'
Length of output: 368
v3/internal/doctor/packagemanager/nixpkgs.go (3)
71-74: LGTM! Clean implementation of optional package support
The changes effectively handle optional packages while maintaining backward compatibility. The use of InstallCheck callback provides good flexibility for custom installation verification.
151-151: LGTM! Clean implementation of custom install commands
The change simplifies the logic while maintaining the expected behavior for both system and non-system packages.
58-60: Consider version pinning and PATH verification for nfpm installation
While the implementation correctly marks nfpm as optional and uses a custom install method, there are two potential improvements:
- Consider pinning the nfpm version instead of using @latest to ensure consistent behavior
- Verify that GOPATH/bin is in PATH when using go install
Consider updating the InstallCommand to a specific version:
-InstallCommand: "go install github.com/goreleaser/nfpm/v2/cmd/nfpm@latest"
+InstallCommand: "go install github.com/goreleaser/nfpm/v2/cmd/nfpm@v2.30.1"v3/internal/doctor/packagemanager/packagemanager.go (1)
137-140: LGTM! Clean addition of nfpm version check
The addition follows the established pattern and maintains consistency with other package manager version checks.
v3/internal/doctor/doctor.go (1)
12-13: LGTM: Import organization improvement
The separation of the buildinfo import improves code organization and readability.
mkdocs-website/docs/en/changelog.md (2)
21-21: LGTM! Linux packaging support entry aligns with PR objectives.
The changelog entry accurately reflects the PR objectives, documenting the addition of support for deb, rpm, and arch linux packager builds.
Line range hint 1-20: LGTM! Changelog follows proper format.
The file correctly follows the Keep a Changelog format and includes all necessary sections:
- Header with format explanation
- Clear categorization (Added, Changed, Deprecated, etc.)
- Proper linking format for references
| "nfpm": []*Package{ | ||
| {Name: "nfpm", SystemPackage: false, InstallCheck: isNfpmInstalled, InstallCommand: "go install github.com/goreleaser/nfpm/v2/cmd/nfpm@latest", Optional: true}, | ||
| }, |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider pinning nfpm to a specific version.
Using @latest in the install command could lead to unexpected behavior if a breaking change is introduced. Consider pinning to a specific version for better reproducibility and security.
- {Name: "nfpm", SystemPackage: false, InstallCheck: isNfpmInstalled, InstallCommand: "go install github.com/goreleaser/nfpm/v2/cmd/nfpm@latest", Optional: true},
+ {Name: "nfpm", SystemPackage: false, InstallCheck: isNfpmInstalled, InstallCommand: "go install github.com/goreleaser/nfpm/v2/cmd/nfpm@v2.35.3", Optional: true},📝 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.
| "nfpm": []*Package{ | |
| {Name: "nfpm", SystemPackage: false, InstallCheck: isNfpmInstalled, InstallCommand: "go install github.com/goreleaser/nfpm/v2/cmd/nfpm@latest", Optional: true}, | |
| }, | |
| "nfpm": []*Package{ | |
| {Name: "nfpm", SystemPackage: false, InstallCheck: isNfpmInstalled, InstallCommand: "go install github.com/goreleaser/nfpm/v2/cmd/nfpm@v2.35.3", Optional: true}, | |
| }, |
| func isNfpmInstalled() bool { | ||
| _, err := exec.LookPath("nfpm") | ||
| return err == nil | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider reusing existing commandExists function
The isNfpmInstalled function duplicates the logic already present in the commandExists function. Additionally, it appears to be unused in the current file.
Consider removing this function and using the existing commandExists function instead:
-func isNfpmInstalled() bool {
- _, err := exec.LookPath("nfpm")
- return err == nil
-}If this function is needed for external use, consider:
- Adding documentation explaining its purpose
- Reusing the
commandExistsfunction internally:
+// isNfpmInstalled checks if nfpm package manager is available in the system
+func isNfpmInstalled() bool {
+ return commandExists("nfpm")
+}📝 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.
| func isNfpmInstalled() bool { | |
| _, err := exec.LookPath("nfpm") | |
| return err == nil | |
| } | |
| // isNfpmInstalled checks if nfpm package manager is available in the system | |
| func isNfpmInstalled() bool { | |
| return commandExists("nfpm") | |
| } |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (2)
v3/internal/commands/build_assets/Taskfile.linux.yml (2)
82-110: Consider reducing code duplication in generate tasksThe precondition check for nfpm is duplicated across all three generate tasks. Consider moving common elements to a shared task.
_check_nfpm: # Internal task preconditions: - sh: nfpm --version msg: It appears nfpm is not installed. Please install using `go install github.com/goreleaser/nfpm/v2/cmd/nfpm@latest` generate:deb: deps: [_check_nfpm] summary: Creates a deb package cmds: - nfpm pkg -f ./build/nfpm/nfpm.yaml -p deb -t ./bin/{{.APP_NAME}}.deb env: GOARCH: '{{.ARCH | default ARCH}}'🧰 Tools
🪛 yamllint (1.29.0-1)
[error] 87-87: trailing spaces
(trailing-spaces)
[error] 97-97: trailing spaces
(trailing-spaces)
[error] 107-107: trailing spaces
(trailing-spaces)
82-110: Clean up formatting and consider parameterizing paths
- Remove trailing spaces after
cmds:in all generate tasks- Consider parameterizing common paths and file extensions
generate:deb: summary: Creates a deb package preconditions: - sh: nfpm --version msg: It appears nfpm is not installed. Please install using `go install github.com/goreleaser/nfpm/v2/cmd/nfpm@latest` - cmds: - - nfpm pkg -f ./build/nfpm/nfpm.yaml -p deb -t ./bin/{{.APP_NAME}}.deb + cmds: + - nfpm pkg -f {{.NFPM_CONFIG}} -p deb -t {{.BIN_DIR}}/{{.APP_NAME}}.deb env: GOARCH: '{{.ARCH | default ARCH}}'🧰 Tools
🪛 yamllint (1.29.0-1)
[error] 87-87: trailing spaces
(trailing-spaces)
[error] 97-97: trailing spaces
(trailing-spaces)
[error] 107-107: trailing spaces
(trailing-spaces)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
v3/internal/commands/build_assets/Taskfile.linux.yml(2 hunks)
🧰 Additional context used
🪛 yamllint (1.29.0-1)
v3/internal/commands/build_assets/Taskfile.linux.yml
[error] 87-87: trailing spaces
(trailing-spaces)
[error] 97-97: trailing spaces
(trailing-spaces)
[error] 107-107: trailing spaces
(trailing-spaces)
🔇 Additional comments (1)
v3/internal/commands/build_assets/Taskfile.linux.yml (1)
55-81: LGTM! Well-structured create tasks
The create tasks for deb, rpm, and aur packages are well-organized with consistent structure and proper production build dependencies.
Fixed task update.
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Outside diff range and nitpick comments (12)
v3/internal/flags/package.go (2)
4-9: Consider using an enum type for package formats.While the current implementation works, using string literals for package formats could lead to runtime errors if invalid formats are provided. Consider using an enumerated type for better type safety and IDE support.
Here's a suggested implementation:
+// PackageFormat represents supported Linux package formats +type PackageFormat string + +const ( + PackageFormatDeb PackageFormat = "deb" + PackageFormatRPM PackageFormat = "rpm" + PackageFormatArchLinux PackageFormat = "archlinux" +) + +func (f PackageFormat) IsValid() bool { + switch f { + case PackageFormatDeb, PackageFormatRPM, PackageFormatArchLinux: + return true + } + return false +} type ToolPackage struct { Common - Format string `name:"format" description:"Package format to generate (deb, rpm, archlinux)" default:"deb"` + Format PackageFormat `name:"format" description:"Package format to generate (deb, rpm, archlinux)" default:"deb"` ConfigPath string `name:"config" description:"Path to the package configuration file" default:""` }
5-5: Document the embedded Common struct.The embedded
Commonstruct's purpose and fields should be documented for better understanding of the complete configuration options available.Add a comment explaining what
Commonprovides:type ToolPackage struct { + // Common provides shared configuration options for all tools Commonv3/internal/commands/tool_package.go (1)
13-13: Enhance function documentationConsider adding more comprehensive documentation for this exported function, including:
- Parameter description
- Return value description
- Example usage with different package formats
- Any prerequisites (like nfpm installation)
-// ToolPackage generates a Linux package in the specified format using nfpm +// ToolPackage generates a Linux package in the specified format using nfpm. +// It supports generating .deb, .rpm, and Arch Linux packages. +// +// Parameters: +// - options: Configuration options including the package format and config file path +// +// Returns: +// - error: If package generation fails or if inputs are invalid +// +// Example: +// +// err := ToolPackage(&flags.ToolPackage{ +// Format: "deb", +// ConfigPath: "nfpm.yaml", +// })v3/internal/packager/packager_test.go (2)
10-24: Consider extracting test setup into helper functions.The test setup logic could be moved into helper functions to improve readability and reusability. This would make the test more maintainable and easier to understand.
Consider refactoring like this:
+func createTempFileWithContent(t *testing.T, content []byte) (string, func()) { + tmpfile, err := os.CreateTemp("", "example") + if err != nil { + t.Fatal(err) + } + + if _, err := tmpfile.Write(content); err != nil { + t.Fatal(err) + } + if err := tmpfile.Close(); err != nil { + t.Fatal(err) + } + + return tmpfile.Name(), func() { os.Remove(tmpfile.Name()) } +} func TestCreatePackageFromConfig(t *testing.T) { - // Create a temporary file for testing - content := []byte("test content") - tmpfile, err := os.CreateTemp("", "example") - if err != nil { - t.Fatal(err) - } - defer os.Remove(tmpfile.Name()) - - if _, err := tmpfile.Write(content); err != nil { - t.Fatal(err) - } - if err := tmpfile.Close(); err != nil { - t.Fatal(err) - } + tmpfileName, cleanup := createTempFileWithContent(t, []byte("test content")) + defer cleanup()
64-91: Enhance test coverage and performance.Consider the following improvements:
- Add parallel test execution using
t.Parallel().- Add more specific assertions about package content.
- Test package size and basic structure.
for _, format := range formats { t.Run(string(format.pkgType), func(t *testing.T) { + t.Parallel() // Test file-based package creation outputPath := filepath.Join(os.TempDir(), "test-package."+format.ext) err := CreatePackageFromConfig(format.pkgType, configFile.Name(), outputPath) if err != nil { t.Errorf("CreatePackageFromConfig failed for %s: %v", format.pkgType, err) } defer os.Remove(outputPath) // Verify the file was created if _, err := os.Stat(outputPath); os.IsNotExist(err) { t.Errorf("Package file was not created for %s", format.pkgType) } + + // Verify package size + info, err := os.Stat(outputPath) + if err != nil { + t.Errorf("Failed to get package info: %v", err) + } + if info.Size() == 0 { + t.Error("Package file is empty") + }v3/internal/packager/packager.go (2)
33-66: Consider adding security checks for file operations.While the error handling is robust, consider adding:
- File permission checks for the output file
- Path validation for the config file
- Size limits for the output file
Here's a suggested improvement:
func CreatePackageFromConfig(pkgType PackageType, configPath string, output string) error { + // Validate paths + if !filepath.IsAbs(configPath) { + configPath = filepath.Clean(filepath.Join(filepath.Dir(os.Args[0]), configPath)) + } + if !filepath.IsAbs(output) { + output = filepath.Clean(filepath.Join(filepath.Dir(os.Args[0]), output)) + } + // Parse nfpm config config, err := nfpm.ParseFile(configPath) if err != nil { return fmt.Errorf("error parsing config file: %w", err) }
1-94: Consider adding comprehensive test coverage.The package would benefit from:
- Unit tests for each package format
- Integration tests with sample config files
- Error case testing
- Mock implementations for the file system operations
Would you like me to help generate a test suite for this package?
v3/internal/commands/tool_package_test.go (2)
12-95: Consider adding more test cases for comprehensive coverage.While the current test cases cover format validation and file existence, consider adding:
- Test cases for invalid config file content
- Test cases verifying successful package generation
- Test cases for handling permission errors
Here's a suggested additional test case for invalid config content:
{ + name: "should fail with invalid config content", + setup: func() (*flags.ToolPackage, func()) { + dir := t.TempDir() + configPath := filepath.Join(dir, "config.yaml") + err := os.WriteFile(configPath, []byte("invalid: ["), 0644) + if err != nil { + t.Fatal(err) + } + + return &flags.ToolPackage{ + Format: "deb", + ConfigPath: configPath, + }, func() {} + }, + wantErr: true, + errMsg: "failed to parse config", + },
97-114: Consider enabling parallel test execution and adding timeout protection.The test execution logic is solid, but could be enhanced for better performance and reliability:
Apply this diff to enable parallel execution and add timeout protection:
for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { + t.Parallel() + + done := make(chan struct{}) + go func() { options, cleanup := tt.setup() defer cleanup() err := ToolPackage(options) if (err != nil) != tt.wantErr { t.Errorf("ToolPackage() error = %v, wantErr %v", err, tt.wantErr) - return + close(done) + return } if tt.wantErr && !strings.Contains(err.Error(), tt.errMsg) { t.Errorf("ToolPackage() error = %v, want error containing %v", err, tt.errMsg) } + close(done) + }() + + select { + case <-done: + case <-time.After(30 * time.Second): + t.Fatal("test timed out") + } }) }Don't forget to add
"time"to the imports.v3/cmd/wails3/main.go (1)
75-75: Consider renaming to avoid command name confusionWhile the implementation is correct, having both
wails3 packageandwails3 tool packagecommands might confuse users. Consider renaming the tool subcommand to be more specific, e.g.,wails3 tool linux-packageorwails3 tool create-package.-tool.NewSubCommandFunction("package", "Generate Linux packages (deb, rpm, archlinux)", commands.ToolPackage) +tool.NewSubCommandFunction("linux-package", "Generate Linux packages (deb, rpm, archlinux)", commands.ToolPackage)v3/go.mod (1)
Based on the search results, I can now provide a definitive response about the Go version requirement:
Consider lowering the Go version requirement
The codebase uses Go 1.22 features sparingly:
min/maxbuilt-in functions in a few places in screen management and generator codeclearbuilt-in in event handling and struct collection- No usage of range-over-string-runes or range-over-array-copy features
These features could be easily replaced with standard library alternatives to maintain compatibility with Go 1.21, which would make the project more accessible to users who haven't upgraded yet.
🔗 Analysis chain
Line range hint
3-3: Verify Go version compatibility requirementsThe module requires Go 1.22.4, which is quite recent. Consider if this requirement aligns with the project's compatibility goals and user base needs.
Let me analyze the search results and generate additional verification scripts to check for Go 1.22-specific features.
This will help us determine if the codebase actually uses any Go 1.22 specific features that would justify requiring this version.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if any code uses features specific to Go 1.22 rg -l 'range.*over.*string.*runes|range.*over.*array.*copy|clear|min|max'Length of output: 100203
Script:
#!/bin/bash # Check v3 module for Go 1.22 specific features # 1. Check for range over array copy rg -p 'range.*\[' v3/ # 2. Check for clear built-in usage rg -p '\bclear\(' v3/ # 3. Check for min/max built-in usage rg -p '\b(min|max)\(' v3/ # 4. Check for any other Go 1.22 specific syntax rg -p 'for.*range.*runes' v3/Length of output: 83552
v3/internal/commands/task.go (1)
110-112: Simplify condition for silent task listingThe condition has been simplified by removing unnecessary parentheses, enhancing code readability:
-if (listOptions.ShouldListTasks()) && options.Silent { +if listOptions.ShouldListTasks() && options.Silent {
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (1)
v3/go.sumis excluded by!**/*.sum
📒 Files selected for processing (8)
v3/cmd/wails3/main.go(1 hunks)v3/go.mod(3 hunks)v3/internal/commands/task.go(4 hunks)v3/internal/commands/tool_package.go(1 hunks)v3/internal/commands/tool_package_test.go(1 hunks)v3/internal/flags/package.go(1 hunks)v3/internal/packager/packager.go(1 hunks)v3/internal/packager/packager_test.go(1 hunks)
🔇 Additional comments (17)
v3/internal/flags/package.go (2)
1-4: LGTM! Clear package declaration and documentation.
The package declaration and struct documentation are clear and concise.
8-8: Consider validating config file path.
The ConfigPath field might benefit from validation to ensure it points to a valid nFPM configuration file when specified.
Let's check if there are any existing validation mechanisms in the codebase:
✅ Verification successful
Config file path validation is already implemented
The codebase already has comprehensive validation for the config file path in v3/internal/commands/tool_package.go:
- Checks if config path is provided
- Converts to absolute path
- Verifies file existence
- The config is also validated during parsing via
nfpm.ParseFile()
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Look for config validation patterns in the codebase
# Expected: Find validation logic for config files
# Search for config validation patterns
rg -A 5 "ValidateConfig|validateConfig|ConfigPath|configPath"
# Search for nFPM config related code
rg -A 5 "nfpm\.yaml|\.nfpm"
Length of output: 8266
v3/internal/commands/tool_package.go (3)
1-11: LGTM: Clean imports and package declaration
The imports are well-organized and necessary for the functionality.
49-52: Consider error recovery and cleanup
If package creation fails, there might be temporary files or partial outputs that need cleanup.
Let's check if the packager handles cleanup:
Consider adding cleanup logic:
+outputPath := filepath.Join(".", outputFile)
+defer func() {
+ if err != nil {
+ // Clean up partial/failed output
+ if _, statErr := os.Stat(outputPath); statErr == nil {
+ os.Remove(outputPath)
+ }
+ }
+}()
err = packager.CreatePackageFromConfig(pkgType, configPath, outputFile)
if err != nil {
return fmt.Errorf("error creating package: %w", err)
}41-43: Enhance config file validation
The code only checks if the config file exists but doesn't validate its content.
Let's verify the config file validation in the packager package:
Consider adding basic YAML validation before passing to nfpm:
+import "gopkg.in/yaml.v3"
+
if _, err := os.Stat(configPath); err != nil {
return fmt.Errorf("config file not found: %s", configPath)
}
+
+// Validate YAML syntax
+configData, err := os.ReadFile(configPath)
+if err != nil {
+ return fmt.Errorf("error reading config file: %w", err)
+}
+var config map[string]interface{}
+if err := yaml.Unmarshal(configData, &config); err != nil {
+ return fmt.Errorf("invalid YAML in config file: %w", err)
+}v3/internal/packager/packager_test.go (2)
1-8: LGTM!
The package declaration and imports are appropriate for the test file.
26-50: 🛠️ Refactor suggestion
Verify YAML configuration validity.
Consider adding test cases to verify the YAML configuration is valid and contains all required fields. Also, consider testing with invalid YAML syntax.
+func TestCreatePackageFromConfigWithInvalidYAML(t *testing.T) {
+ configContent := []byte(`
+invalid:
+ yaml: [syntax
+ `)
+
+ configFile, err := os.CreateTemp("", "config*.yaml")
+ if err != nil {
+ t.Fatal(err)
+ }
+ defer os.Remove(configFile.Name())
+
+ if _, err := configFile.Write(configContent); err != nil {
+ t.Fatal(err)
+ }
+
+ err = CreatePackageFromConfig(DEB, configFile.Name(), "output.deb")
+ if err == nil {
+ t.Error("Expected error for invalid YAML, got nil")
+ }
+}v3/internal/packager/packager.go (2)
1-15: LGTM! Well-structured package declaration and imports.
The package documentation clearly states its purpose, and the imports are properly organized with necessary blank imports to register different package formats.
17-31: Consider enhancing package format documentation.
While the constants are well-defined, consider adding more detailed documentation about:
- Version compatibility
- Required dependencies
- Typical use cases for each format
Also, the PR objectives only mention deb, rpm, and arch support, but the code includes APK and IPK formats.
Let's verify if these additional formats are being used:
v3/internal/commands/tool_package_test.go (2)
1-10: LGTM! Clean and minimal imports.
The package declaration and imports are appropriate for the test requirements.
1-114: Verify integration tests for package generation.
While these unit tests cover format validation well, we should ensure there are integration tests that verify actual package generation for each format (deb, rpm, arch) as mentioned in the PR objectives.
✅ Verification successful
Let's examine the content of the packager tests to verify the coverage.
Integration tests for package generation are present and comprehensive
The packager_test.go contains thorough integration tests that:
- Test actual package generation for all supported formats (deb, rpm, and arch linux)
- Verify both file-based and writer-based package creation
- Include validation of package file creation
- Test error cases with invalid configurations
- Cover package metadata and content configuration
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for integration tests covering package generation
# Look for test files that might contain package generation tests
echo "Searching for package generation tests..."
rg -l "TestPackageGeneration|TestCreatePackage|test.*package" --type go
# Look for specific package format testing
echo -e "\nSearching for specific format testing..."
rg -l "\.deb|\.rpm|\.pkg\.tar\.zst" --type go
Length of output: 1768
Script:
#!/bin/bash
# Check the content of packager tests
cat v3/internal/packager/packager_test.go
Length of output: 2427
v3/cmd/wails3/main.go (1)
75-75: Verify command help text distinction
Let's verify that the help text clearly distinguishes between the root-level package command and the tool package command to prevent user confusion.
✅ Verification successful
Help texts are sufficiently distinct and clear
The command help texts are clearly distinct:
- Root
packagecommand: "Package application" - Tool
packagecommand: "Generate Linux packages (deb, rpm, archlinux)"
The descriptions effectively differentiate between the general packaging command and the Linux-specific packaging tool, preventing user confusion.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check help text for both package commands to ensure they are distinct
# Test 1: Check root package command help
echo "=== Root package command help ==="
./wails3 package --help
# Test 2: Check tool package command help
echo "=== Tool package command help ==="
./wails3 tool package --help
# Test 3: Search for any documentation mentioning both commands
echo "=== Documentation mentioning package commands ==="
fd -e md -e txt . | xargs rg -l "wails3 (tool )?package"
Length of output: 1072
Script:
#!/bin/bash
# Let's try a different approach to verify the command help text distinction
# by examining the source code directly
# Check the root package command implementation
echo "=== Root package command implementation ==="
ast-grep --pattern 'NewCommand("package",$$$)' -l go
# Check the tool package command implementation
echo "=== Tool package command implementation ==="
ast-grep --pattern 'NewSubCommandFunction("package",$$$)' -l go
# Search for command descriptions in the codebase
echo "=== Command descriptions ==="
rg "package.*command.*description" -i
# Look for help text definitions
echo "=== Help text definitions ==="
rg "package.*help.*text" -i
Length of output: 520
Script:
#!/bin/bash
# Let's try one more approach to find the command implementations and their descriptions
# Find all package-related command definitions
echo "=== Package command definitions ==="
rg '"package".*Generate' -A 2 -B 2
# Find files containing package command implementations
echo "=== Files with package commands ==="
fd -e go | xargs rg -l "package.*Generate"
# Look for the command registration in main.go
echo "=== Main package command registration ==="
cat v3/cmd/wails3/main.go
Length of output: 5757
v3/go.mod (2)
73-73: Packaging dependencies align with PR objectives
The addition of nfpm, rpmpack, and related dependencies appropriately supports the new Linux packaging functionality. These are well-maintained libraries suitable for creating deb, rpm, and arch packages.
Also applies to: 75-75, 76-76, 77-77
✅ Verification successful
Packaging dependencies are stable and well-integrated
The verification confirms:
- goreleaser/nfpm is actively maintained with latest release v2.41.1 (November 2024)
- google/rpmpack is stable with recent commits (October 2024) and proper version pinning
- Both dependencies are properly integrated across multiple package manager implementations in the codebase
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify the stability of new packaging dependencies
gh api graphql -f query='
{
repository(owner: "goreleaser", name: "nfpm") {
releases(first: 1) {
nodes {
tagName
publishedAt
}
}
}
}'
Length of output: 283
Script:
#!/bin/bash
# Check rpmpack's recent activity and stability
gh api graphql -f query='
{
repository(owner: "google", name: "rpmpack") {
releases(first: 1) {
nodes {
tagName
publishedAt
}
}
defaultBranchRef {
target {
... on Commit {
history(first: 5) {
nodes {
committedDate
messageHeadline
}
}
}
}
}
}
}'
# Check if these dependencies are being used in the codebase
rg -l "nfpm|rpmpack" --type go
Length of output: 1558
10-10: Verify security implications of dependency updates
Several core dependencies have been updated, including crypto-related packages. While updates are generally good for security, please verify:
- No breaking changes in go-git v5.12.0
- Compatibility with existing crypto operations
- Security advisories for updated compression libraries
Also applies to: 16-16, 59-59, 88-88, 123-123
✅ Verification successful
Let me gather more information about the dependency updates and their potential impact.
Dependency updates are safe to proceed
The verification shows:
- No security vulnerabilities reported for go-git/v5
- go-git v5.12.0 changes are primarily feature additions and bug fixes, with crypto-related improvements:
- Fixed usage of crypto.Signer interface
- Added crypto.Signer option to CommitOptions
- Other notable updates include:
- ProtonMail/go-crypto to v1.0.0
- cloudflare/circl to v1.3.8
- All changes maintain backward compatibility
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for security advisories in updated dependencies
gh api graphql -f query='
{
securityVulnerabilities(first: 5, ecosystem: GO, package: "github.com/go-git/go-git") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'
Length of output: 356
Script:
#!/bin/bash
# Check go.mod changes to understand version updates
git diff HEAD^1 HEAD -- v3/go.mod
# Check for any breaking changes or security fixes in release notes
curl -s https://api.github.com/repos/go-git/go-git/releases/tags/v5.12.0 | jq -r '.body'
# Look for any crypto-related imports that might be affected
rg -l "crypto" v3/
Length of output: 10120
v3/internal/commands/task.go (3)
81-83: Ensure consistent validation for output group options
The additional check for options.OutputGroupEnd enhances validation by ensuring that the --output-group-end option cannot be set without specifying --output=group. This change aligns with the existing check for options.OutputGroupBegin, promoting consistency in option validation.
14-14: Verify correct import path and update references
The import statement now uses github.com/go-task/task/v3/taskfile/ast. Please ensure that this change aligns with the restructuring of the taskfile package and that all references to the old taskfile package have been updated accordingly to prevent any import errors.
Run the following script to find any remaining import statements that may need to be updated:
This script will help identify any instances where the old taskfile package is still being imported without the /ast suffix.
✅ Verification successful
Based on the search results, I can now generate the final response:
Import path is correctly used and references are properly updated
The import github.com/go-task/task/v3/taskfile/ast is correctly used in the codebase. The search results show that:
- This is the only taskfile-related import in use
- The
astpackage is properly referenced in the code (e.g.,ast.Callin task.go) - No old/incorrect taskfile import paths were found
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find import statements using 'github.com/go-task/task/v3/taskfile' without '/ast'
# Search for import statements that import 'taskfile' without '/ast'
rg 'import.*"github.com/go-task/task/v3/taskfile"$' -t go
Length of output: 59
Script:
#!/bin/bash
# Let's do a broader search for taskfile imports and usages
# Search for any imports containing taskfile
rg '"github.com/go-task/task/v3/taskfile' -t go
# Also search for any references to taskfile package
ast-grep --pattern 'taskfile.$_'
Length of output: 156
Script:
#!/bin/bash
# Let's check for any references to ast package and its usage
# Search for ast package usage
rg 'ast\.' -t go -A 2
# Also check all go files in the taskfile directory
fd '\.go$' 'taskfile' --exec cat {}
Length of output: 15965
105-107: Update 'listOptions' initialization with new parameter
The call to task.NewListOptions now includes an additional parameter false. Verify that this change corresponds to an updated function signature and that the boolean value false correctly represents the new parameter's intended purpose.
Run the following script to confirm the parameters of NewListOptions:
This will help ensure that NewListOptions now accepts four parameters and clarify what the new parameter represents.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (4)
v3/internal/flags/package.go (2)
1-2: Add package documentation.Consider adding a package-level documentation comment to describe the purpose and usage of this package. This will improve code maintainability and help other developers understand the package's role in Linux packaging.
package flags + +// Package flags provides configuration structures for various CLI commands +// related to application packaging and building across different Linux distributions.
7-9: Consider adding validation and security measures.Several improvements could enhance the robustness of this configuration:
- The
Formatfield should be validated against a predefined list of supported formats- The
ExecutableNameshould be sanitized to prevent command injection- The
ConfigPathshould be validated when non-emptyConsider implementing these improvements:
type ToolPackage struct { Common - - Format string `name:"format" description:"Package format to generate (deb, rpm, archlinux)" default:"deb"` - ExecutableName string `name:"name" description:"Name of the executable to package" default:"myapp"` - ConfigPath string `name:"config" description:"Path to the package configuration file" default:""` + // Format specifies the package type to generate. + // Supported values: deb, rpm, archlinux + Format string `name:"format" description:"Package format to generate (deb, rpm, archlinux)" default:"deb" validate:"oneof=deb rpm archlinux"` + + // ExecutableName is the name of the executable to package. + // This will be sanitized to prevent command injection. + ExecutableName string `name:"name" description:"Name of the executable to package" default:"myapp" validate:"required,filename"` + + // ConfigPath is the path to the nFPM configuration file. + // If empty, the default configuration will be used. + ConfigPath string `name:"config" description:"Path to the package configuration file" default:"" validate:"omitempty,file"`Additionally, consider implementing a validation method:
// Validate performs validation and sanitization of ToolPackage fields func (t *ToolPackage) Validate() error { // Add validation logic here return nil }v3/internal/commands/build_assets/Taskfile.linux.yml (2)
73-73: Fix inconsistent terminology in task summaryThe summary uses "arch linux packager package" which is inconsistent with the common terminology. Consider changing it to "Creates an Arch Linux package" for clarity and consistency.
83-83: Remove trailing spacesRemove trailing spaces from the following lines:
- Line 83:
cmds:- Line 88:
cmds:- Line 93:
cmds:Also applies to: 88-88, 93-93
🧰 Tools
🪛 yamllint (1.29.0-1)
[error] 83-83: trailing spaces
(trailing-spaces)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
v3/internal/commands/build_assets/Taskfile.linux.yml(2 hunks)v3/internal/commands/tool_package.go(1 hunks)v3/internal/flags/package.go(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- v3/internal/commands/tool_package.go
🧰 Additional context used
🪛 yamllint (1.29.0-1)
v3/internal/commands/build_assets/Taskfile.linux.yml
[error] 83-83: trailing spaces
(trailing-spaces)
[error] 88-88: trailing spaces
(trailing-spaces)
[error] 93-93: trailing spaces
(trailing-spaces)
🔇 Additional comments (2)
v3/internal/flags/package.go (2)
1-10: Verify nFPM integration and configuration handling.
Since this struct will be used with nFPM for package generation, we should verify the configuration handling.
✅ Verification successful
Let me gather more specific information about the nFPM integration by checking the implementation details.
nFPM integration is properly implemented and configuration handling is verified
The codebase shows a well-structured nFPM integration:
- The
packagerpackage properly imports and uses the nFPM library with support for multiple package formats (DEB, RPM, APK, IPK, ARCH) - Configuration handling is implemented correctly through
nfpm.ParseFile()inCreatePackageFromConfig - The
ToolPackagestruct fields align with the package generation requirements and are properly utilized in the command implementation
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check nFPM configuration and integration points
echo "Checking nFPM configuration handling..."
# Search for nFPM configuration parsing
rg -l "nfpm" --type go
# Search for package generation logic
ast-grep --pattern 'func $_(options *flags.ToolPackage) {
$$$
}'
Length of output: 604
Script:
#!/bin/bash
# Check the actual nFPM integration in packager.go and tool_package.go
echo "Checking packager implementation..."
cat v3/internal/packager/packager.go
echo -e "\nChecking package command implementation..."
cat v3/internal/commands/tool_package.go
# Search for any nFPM config struct or interface definitions
echo -e "\nChecking for nFPM related types..."
rg -A 5 "type.*[Nn]fpm" --type go
Length of output: 4580
3-6: Enhance struct documentation and verify Common struct usage.
The current documentation could be more descriptive about the struct's role in Linux packaging.
-// ToolPackage represents the options for the package command
+// ToolPackage represents the configuration options for creating Linux distribution
+// packages (deb, rpm, archlinux) using nFPM. It extends the Common configuration
+// with package-specific options.
type ToolPackage struct {Let's verify the Common struct's purpose:
✅ Verification successful
Let me gather more information about the package command and its usage to better understand the context.
Let me check the package command implementation and the nfpm configuration template to better understand the context.
Documentation improvement suggestion is accurate but needs refinement
The struct documentation should be enhanced as it's used for Linux package generation via nFPM, with specific format support for deb, rpm, and archlinux packages. The embedded Common struct (providing NoColour option) is appropriately used for shared CLI functionality.
-// ToolPackage represents the options for the package command
+// ToolPackage represents the configuration options for generating Linux distribution
+// packages (deb, rpm, archlinux) using nFPM. It embeds Common for shared CLI options
+// and adds package-specific configuration like format and output naming.
type ToolPackage struct {🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check the Common struct definition and its usage
rg -A 5 "type Common struct" v3/internal/flags/
Length of output: 212
Script:
#!/bin/bash
# Check for package command usage and documentation
rg -B 2 -A 5 "package" v3/internal/flags/package.go
# Check for nfpm related code or configuration
rg -l "nfpm" .
# Look for any package command implementation
ast-grep --pattern 'func $_(package $$$) $$$'
Length of output: 7361
Script:
#!/bin/bash
# Check the package command implementation
cat v3/internal/commands/tool_package.go
# Check the nfpm template
cat v3/internal/commands/updatable_build_assets/nfpm/nfpm.yaml.tmpl
# Check the packager implementation
cat v3/internal/packager/packager.go
Length of output: 5471
empty name guard
atterpac
force-pushed
the
v3/linux-packaging
branch
from
8a30737 to
8d7f763
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (2)
v3/internal/commands/tool_package.go (1)
13-14: Enhance function documentationConsider adding more detailed documentation that includes:
- Description of input parameters and their expected values
- Explanation of error conditions and return values
- Examples of usage
-// ToolPackage generates a Linux package in the specified format using nfpm +// ToolPackage generates a Linux package in the specified format using nfpm. +// It accepts configuration options through flags.ToolPackage which must include: +// - ConfigPath: Path to the nfpm configuration file +// - ExecutableName: Name of the executable to package +// - Format: Package format (supported: "deb", "rpm", "archlinux") +// +// The function returns an error if: +// - Required options are missing +// - Config file is not found or inaccessible +// - Package format is unsupported +// - Package creation failsv3/internal/commands/build_assets/Taskfile.linux.yml (1)
83-83: Fix trailing spaces in generate tasksRemove trailing spaces after
cmds:in the generate tasks for consistent formatting.- cmds: + cmds:Also applies to: 88-88, 93-93
🧰 Tools
🪛 yamllint (1.29.0-1)
[error] 83-83: trailing spaces
(trailing-spaces)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
v3/internal/commands/build_assets/Taskfile.linux.yml(2 hunks)v3/internal/commands/tool_package.go(1 hunks)v3/internal/flags/package.go(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- v3/internal/flags/package.go
🧰 Additional context used
🪛 yamllint (1.29.0-1)
v3/internal/commands/build_assets/Taskfile.linux.yml
[error] 83-83: trailing spaces
(trailing-spaces)
[error] 88-88: trailing spaces
(trailing-spaces)
[error] 93-93: trailing spaces
(trailing-spaces)
🔇 Additional comments (5)
v3/internal/commands/tool_package.go (3)
15-15: Global state modification issue still exists
25-36: LGTM! Package format validation is thorough
The validation correctly handles all supported formats (deb, rpm, archlinux) and provides clear error messages.
56-60: Verify packager dependency implementation
Let's verify the packager.CreatePackageFromConfig implementation to ensure it properly handles all package types.
✅ Verification successful
Let me gather more information about the package types and their handling.
Let me check one more thing about the nfpm package usage to ensure proper implementation.
Packager dependency implementation is properly structured and handles all package types
The implementation correctly:
- Supports all major package types (DEB, RPM, APK, IPK, ARCH)
- Uses nfpm library for package creation with proper error handling
- Implements consistent package creation flow with config parsing and type validation
- Has corresponding test coverage
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify packager implementation for all supported package types
# Check packager implementation
ast-grep --pattern $'func CreatePackageFromConfig(pkgType PackageType, configPath string, outputFile string) error {
$$$
}'
# Check package type definitions
ast-grep --pattern $'type PackageType $_'
Length of output: 229
Script:
#!/bin/bash
# Search for package type constants and CreatePackageFromConfig implementation
rg -A 10 "const \(" v3/internal/packager/packager.go
# Search for actual implementation of CreatePackageFromConfig
rg -A 20 "func CreatePackageFromConfig" v3/internal/packager/packager.go
Length of output: 1675
Script:
#!/bin/bash
# Check nfpm package imports and any custom implementations
rg "nfpm\." v3/internal/packager/packager.go
# Check if there are any other files using the packager
fd packager --exec rg -l "CreatePackageFromConfig"
Length of output: 421
v3/internal/commands/build_assets/Taskfile.linux.yml (2)
31-33: LGTM: Package task properly integrates new Linux formats
The package task correctly includes all Linux package formats (deb, rpm, aur) alongside the existing AppImage format.
54-80: LGTM: Create tasks follow consistent pattern
The create tasks for deb, rpm, and aur packages are well-structured with:
- Proper production build dependency
- Consistent task organization
- Clear task summaries
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (3)
v3/internal/commands/updatable_build_assets/nfpm/nfpm.yaml.tmpl (3)
1-5: Remove misleading modeline referenceThe comment mentions modelines but no actual vim/emacs modelines are present in the file. Consider removing line 4 to avoid confusion.
# Feel free to remove those if you don't want/need to use them. # Make sure to check the documentation at https://nfpm.goreleaser.com # -# The lines below are called `modelines`. See `:help modeline`
27-29: Enhance dependency specificationsConsider the following improvements to the dependencies section:
- Add version constraints to ensure compatibility
- Make dependencies configurable via template variables to support different distribution package names
- Allow applications to specify additional dependencies
depends: - - gtk3 - - libwebkit2gtk +{{- if .Dependencies}} +{{.Dependencies}} +{{- else}} + - gtk3 >= 3.0 + - libwebkit2gtk >= 2.0 +{{- end}}
31-50: Clean up and improve commented configuration examples
- Remove the duplicate dependencies section (lines 35-37)
- Consider moving examples to documentation to keep the template clean
- Add template variables for script paths
-# depends: -# - gtk3 -# - libwebkit2gtk # recommends: # - whatever # suggests: # - something-else # conflicts: # - not-foo # - not-bar # changelog: "changelog.yaml" # scripts: -# preinstall: ./build/nfpm/scripts/preinstall.sh -# postinstall: ./build/nfpm/scripts/postinstall.sh -# preremove: ./build/nfpm/scripts/preremove.sh -# postremove: ./build/nfpm/scripts/postremove.sh +# preinstall: "{{.ScriptsDir}}/preinstall.sh" +# postinstall: "{{.ScriptsDir}}/postinstall.sh" +# preremove: "{{.ScriptsDir}}/preremove.sh" +# postremove: "{{.ScriptsDir}}/postremove.sh"Consider creating a documentation file with comprehensive examples and explanations of all available options. This would keep the template clean while still providing guidance to users.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
v3/internal/commands/build_assets/Taskfile.linux.yml(2 hunks)v3/internal/commands/updatable_build_assets/nfpm/nfpm.yaml.tmpl(1 hunks)
🧰 Additional context used
🪛 yamllint (1.29.0-1)
v3/internal/commands/build_assets/Taskfile.linux.yml
[error] 86-86: trailing spaces
(trailing-spaces)
[error] 91-91: trailing spaces
(trailing-spaces)
[error] 96-96: trailing spaces
(trailing-spaces)
🔇 Additional comments (3)
v3/internal/commands/updatable_build_assets/nfpm/nfpm.yaml.tmpl (1)
1-50: Verify package format compatibility
Please ensure that all fields in the template are compatible with the target package formats (deb, rpm, and arch). Some fields might have different requirements or naming conventions across formats.
✅ Verification successful
Template is compatible with all package formats
The template follows NFPM's standard configuration format which is compatible with all supported package formats (deb, rpm, and arch). The fields used in the template are common across formats:
- Basic metadata (name, version, maintainer, description) is standard
- Dependencies are specified in a format that NFPM automatically translates for each package type
- File mappings use a universal source-to-destination format
- Platform-specific fields are either omitted or commented out for optional use
The template provides a good foundation that works across package formats while allowing customization through the commented sections if needed.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check NFPM documentation for format-specific requirements
# Search for format-specific documentation in the NFPM repository
gh api repos/goreleaser/nfpm/contents/docs \
| jq -r '.[].name' \
| grep -E 'deb|rpm|archlinux'
# Check for any known limitations or format-specific fields
gh api search/code \
-f q='repo:goreleaser/nfpm path:docs format specific OR limitations' \
| jq -r '.items[].path'
Length of output: 388
Script:
#!/bin/bash
# Let's try a different approach by checking the template usage in the codebase
# and any related configuration files that might provide insights
# Search for nfpm config files and their usage
fd -e yaml -e yml . | xargs grep -l "nfpm" || true
# Look for package format related configurations
rg -i "package|format.*deb|format.*rpm|format.*arch" -A 3 -B 3
# Check for any documentation about packaging
fd "README|PACKAGING" | xargs cat
Length of output: 102904
Script:
#!/bin/bash
# Let's check the nfpm.yaml.tmpl file and related files for package format compatibility
# Check the nfpm.yaml.tmpl file content
cat v3/internal/commands/updatable_build_assets/nfpm/nfpm.yaml.tmpl
# Look for any nfpm-related configuration or documentation
rg -l "nfpm" .
# Check for any package format specific configurations
rg -i "deb|rpm|arch" -A 2 -B 2 v3/internal/commands/updatable_build_assets/nfpm/
Length of output: 8664
v3/internal/commands/build_assets/Taskfile.linux.yml (2)
31-33: LGTM! Package task properly includes all Linux package types
The additions align well with the PR objectives to support deb, rpm, and arch linux packaging.
54-83:
Add NFPM config generation as a dependency
The create tasks for deb, rpm, and aur packages need the NFPM configuration file, but there's no task to generate it. Add a prerequisite task to process the template from v3/internal/commands/updatable_build_assets/nfpm/nfpm.yaml.tmpl.
Example fix:
create:deb:
deps:
- task: build
vars:
PRODUCTION: "true"
+ - task: generate:nfpm-config
cmds:
- task: generate:dotdesktop
- task: generate:deb
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (4)
mkdocs-website/docs/en/learn/guides/packaging.md (2)
7-12: Consider adding links to platform-specific documentation.While the Windows and macOS sections are clear, they could be enhanced by adding links to platform-specific documentation for advanced configurations, such as:
- Windows: Code signing, installer customization
- macOS: Code signing, notarization setup, entitlements
68-68: Consider adding troubleshooting and prerequisites sections.The documentation would benefit from additional sections:
- Prerequisites
- Required system dependencies
- nfpm installation instructions
- Troubleshooting
- Common issues and solutions
- Package validation steps
mkdocs-website/docs/en/getting-started/your-first-app.md (2)
88-92: Add output path information for Mac and Windows packages.Consider specifying the exact output paths for the packaged applications to help users locate them easily.
To create a `.app` bundle: ```bash wails3 package-This will create a production build and package it into a
.appbundle in thebindirectory.
+This will create a production build and package it into a.appbundle atbin/myfirstapp.app.Similar change for Windows section: ```diff To create an NSIS installer: ```bash wails3 package-This will create a production build and package it into an NSIS installer in the
bindirectory.
+This will create a production build and package it into an NSIS installer atbin/myfirstapp-installer.exe.Also applies to: 96-100 --- `120-120`: **Consider a more professional tone in the conclusion.** The current conclusion uses an exclamation mark which might seem informal for technical documentation. ```diff -Congratulations! You've just created, developed and packaged your first Wails application. This is just the beginning of what you can achieve with Wails v3. Explore the documentation, experiment with different features, and start building amazing applications! +Congratulations on creating, developing, and packaging your first Wails application. This is just the beginning of what you can achieve with Wails v3. Explore the documentation, experiment with different features, and start building amazing applications.🧰 Tools
🪛 LanguageTool
[style] ~120-~120: Using many exclamation marks might seem excessive (in this case: 7 exclamation marks for a text that’s 3222 characters long)
Context: ... and start building amazing applications!(EN_EXCESSIVE_EXCLAMATION)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
mkdocs-website/docs/en/getting-started/your-first-app.md(1 hunks)mkdocs-website/docs/en/learn/guides/packaging.md(1 hunks)mkdocs-website/mkdocs.yml(2 hunks)
🧰 Additional context used
🪛 LanguageTool
mkdocs-website/docs/en/getting-started/your-first-app.md
[style] ~120-~120: Using many exclamation marks might seem excessive (in this case: 7 exclamation marks for a text that’s 3222 characters long)
Context: ... and start building amazing applications!
(EN_EXCESSIVE_EXCLAMATION)
🔇 Additional comments (4)
mkdocs-website/docs/en/learn/guides/packaging.md (1)
23-23: Verify AppImage support implementation.
The documentation mentions AppImage support and includes a linux:create:appimage task, but this wasn't mentioned in the PR objectives. Please verify if AppImage support is fully implemented.
Also applies to: 34-34
✅ Verification successful
AppImage support is fully implemented
The codebase shows comprehensive AppImage support implementation:
- Complete AppImage generation functionality in
v3/internal/commands/appimage.go - Build scripts and tasks in
build/appimage/directory - Unit tests in
appimage_test.go - Task definitions in
Taskfile.linux.ymlwithlinux:create:appimagetask - Working examples in the file-association example project
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if AppImage-related tasks and configurations exist
echo "Checking for AppImage-related tasks:"
rg "appimage" -i
Length of output: 7623
mkdocs-website/docs/en/getting-started/your-first-app.md (1)
82-83: LGTM! Well-structured addition of packaging instructions.
The new section is logically placed after the build instructions and includes a helpful reference to the detailed packaging guide.
Also applies to: 116-117
mkdocs-website/mkdocs.yml (2)
179-179: LGTM! Copyright line simplification.
The simplified copyright line is legally sufficient and follows common practice.
156-156: LGTM! Verify the target documentation file.
The new navigation item for packaging documentation is well-placed within the guides section.
Let's verify that the target documentation file exists:
✅ Verification successful
Target documentation file exists at the expected location
The file learn/guides/packaging.md exists at the expected location in the documentation structure, confirming that the navigation item correctly points to an existing documentation file.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the packaging documentation file exists
# Expected: File should exist at docs/en/learn/guides/packaging.md
fd -t f "packaging.md" mkdocs-website/docs/
Length of output: 92
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
This PR adds the ability to use nFPM to be able to quickly release packaged applications for specific linux distros including
.deb: Debian based Linux.rpm: Redhat Package Manager (Fedora and friends).pkg.tar.zst: Arch Linux PackagerPR includes doctor adjustments too account for the optional dependency of
nFPMAdds Linux Tasks for
linux:create:deb: Builds production app and creates deb packagelinux:create:rpm: Builds production app and creates rpm packagelinux:create:aur: Builds production app and creates aur tarballlinux:generate:deb: Generates a deb package with the existing app inbin/linux:generate:rpm: Generates a rpm package with the existing app inbin/linux:generate:aur: Generates a tarball with the existing app inbin/Summary by CodeRabbit
Release Notes
New Features
wails3 generate runtimeandwails3 update build-assets.Bug Fixes
AlwaysOnTopfeature on Mac and improved drag-and-drop functionality.Documentation
Chores
go.modfile for improved stability and performance.