0e30e05ce8
* "Add *.profraw files to .gitignore *.profraw files are generated by LLVM's Clang compiler when using the -fprofile-instr-generate option for Profile Guided Optimization. These files contain raw profiling data and should not be version controlled." * Remove redundant import of TryFrom trait The TryFrom trait was being imported explicitly in src\steps\os\windows.rs, even though it's already part of the Rust prelude and automatically imported into every Rust program. This was causing a compiler warning. This commit comments out the redundant import to resolve the warning. * Add GitHub Actions workflow for Rust build and test This commit adds a new GitHub Actions workflow for building and testing the Rust project across multiple operating systems (Ubuntu, Windows, macOS) and Rust versions (stable, beta, nightly). It also includes caching for dependencies and build artifacts, and uploads code coverage reports to Codecov. * Update Codecov action and add token for coverage report upload This commit updates the version of the Codecov GitHub Action used to upload coverage reports from v4 to v4.0.1. It also adds a token from the repository secrets to authenticate the upload. This ensures secure and authorized communication with the Codecov service. * "Fix misuse of --jobs flag in cargo test command" * "Fix grcov command in GitHub Actions workflow The grcov command was previously prefixed with './', which caused an error because grcov was not found in the current directory. This commit removes the './' prefix to call grcov from the global path, where it is installed." * Update GitHub Actions workflow for cross-platform compatibility This commit modifies the 'build-and-test.yml' GitHub Actions workflow to ensure it works correctly across different operating systems (Ubuntu, Windows, MacOS). The RUSTFLAGS environment variable is now set in a cross-platform compatible way. The workflow will run the build and test process on every pull request and push to the main branch, generate a coverage report, and upload it to Codecov. * Changed workflow trigger event to 'workflow_run' completion of 'Build and test' workflow * "Updated GitHub Actions workflow to correctly set environment variables for code coverage" * Renamed build and test workflow * Update GitHub Actions workflow trigger Change the trigger of the 'Test with Code Coverage' workflow to run when the 'build-and-test' workflow is completed. This ensures that code coverage is only calculated after successful build and test runs. * Update workflow_run trigger in code-coverage.yml * Fix CODECOV_TOKEN in code-coverage.yml workflow * Update code-coverage workflow to trigger on pull requests and pushes to main branch * Update .gitignore file to exclude LLVM profiling output * Add empty line at the end * Remove unused import in windows.rs * Update .github/workflows/build-and-test.yml Co-authored-by: SteveLauC <stevelauc@outlook.com> * Update .github/workflows/build-and-test.yml Co-authored-by: SteveLauC <stevelauc@outlook.com> * Remove code coverage workflow --------- Co-authored-by: SteveLauC <stevelauc@outlook.com>
Introduction
Note
This is a fork of topgrade by r-darwish to keep it maintained.
Keeping your system up to date usually involves invoking multiple package managers. This results in big, non-portable shell one-liners saved in your shell. To remedy this, Topgrade detects which tools you use and runs the appropriate commands to update them.
Installation
- Arch Linux: AUR
- NixOS: Nixpkgs
- Void Linux: XBPS
- macOS: Homebrew or MacPorts
- Windows: Scoop or Winget
- PyPi: pip
Other systems users can either use cargo install or the compiled binaries from the release page.
The compiled binaries contain a self-upgrading feature.
Currently, Topgrade requires Rust 1.65 or above. In general, Topgrade tracks the latest stable toolchain.
Usage
Just run topgrade.
Configuration
See config.example.toml for an example configuration file.
Migration and Breaking Changes
Whenever there is a breaking change, the major version number will be bumped, and we will document these changes in the release note, please take a look at it when updated to a major release.
Got a question? Feel free to open an issue or discussion!
Configuration Path
CONFIG_DIR on each platform
- Windows:
%APPDATA% - macOS and other Unix systems:
${XDG_CONFIG_HOME:-~/.config}
topgrade will look for the configuration file in the following places, in order of priority:
CONFIG_DIR/topgrade.tomlCONFIG_DIR/topgrade/topgrade.toml
If the file with higher priority is present, no matter it is valid or not, the other configuration files will be ignored.
On the first run(no configuration file exists), topgrade will create a configuration file at CONFIG_DIR/topgrade.toml for you.
Custom Commands
Custom commands can be defined in the config file which can be run before, during, or after the inbuilt commands, as required.
By default, the custom commands are run using a new shell according to the $SHELL environment variable on unix (falls back to sh) or pwsh on windows (falls back to powershell).
On unix, if you want to run your command using an interactive shell, for example to source your shell's rc files, you can add -i at the start of your custom command.
But note that this requires the command to exit the shell correctly or else the shell will hang indefinitely.
Remote Execution
You can specify a key called remote_topgrades in the configuration file.
This key should contain a list of hostnames that have Topgrade installed on them.
Topgrade will use ssh to run topgrade on remote hosts before acting locally.
To limit the execution only to specific hosts use the --remote-host-limit parameter.
Contribution
Problems or missing features?
Open a new issue describing your problem and if possible provide a solution.
Missing a feature or found an unsupported tool/distro?
Just let us now what you are missing by opening an issue. For tools, please open an issue describing the tool, which platforms it supports and if possible, give us an example of its usage.
Want to contribute to the code?
Just fork the repository and start coding.
Contribution Guidelines
See CONTRIBUTING.md
Roadmap
- Add a proper testing framework to the code base.
- Add unit tests for package managers.
- Split up code into more maintainable parts, eg. putting every linux package manager in a own submodule of linux.rs.