other: master -> main (#1349)

* other: master -> main

I'm so used to using `main` branch now that it's actually kinda annoying
to use `master` for just this repo... so might as well rename it now.

* overzealous change

* wording

* some wording

* allow auto-cancel for tests if not main
This commit is contained in:
Clement Tsang 2023-12-06 00:16:26 -05:00 committed by GitHub
parent bc6a8d7feb
commit dab4b6c483
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
17 changed files with 40 additions and 40 deletions

View file

@ -40,8 +40,8 @@ env:
CARGO_HUSKY_DONT_INSTALL_HOOKS: true
test_task:
auto_cancellation: false
only_if: $CIRRUS_BUILD_SOURCE != "api" && ($CIRRUS_BRANCH == "master" || $CIRRUS_PR != "")
auto_cancellation: $CIRRUS_BRANCH != "main"
only_if: $CIRRUS_BUILD_SOURCE != "api" && ($CIRRUS_BRANCH == "main" || $CIRRUS_PR != "")
skip: "!changesInclude('.cargo/**', '.cirrus.yml', 'sample_configs/**', 'src/**', 'tests/**', 'build.rs', 'Cargo.lock', 'Cargo.toml', 'clippy.toml', 'rustfmt.toml')"
matrix:
- name: "FreeBSD 13 Test"

View file

@ -26,7 +26,7 @@ on:
pull_request:
push:
branches:
- master
- main
env:
RUST_BACKTRACE: 1

View file

@ -30,9 +30,9 @@ jobs:
- name: Clear cache
run: |
if [[ -n "${{ github.event.schedule }}" ]]; then
python ./scripts/clear_cache.py keep-master
python ./scripts/clear_cache.py keep-main
sleep 5
python ./scripts/clear_cache.py keep-master
python ./scripts/clear_cache.py keep-main
elif [[ -z "${{ github.event.inputs.id }}" ]]; then
python ./scripts/clear_cache.py ${{ github.event.pull_request.number }}
sleep 5

View file

@ -10,7 +10,7 @@ on:
pull_request:
push:
branches:
- master
- main
env:
CARGO_INCREMENTAL: 0

View file

@ -5,7 +5,7 @@ on:
workflow_dispatch:
push:
branches:
- master
- main
paths:
- "docs/**"
- ".github/workflows/docs.yml"

View file

@ -20,7 +20,7 @@ If you want to directly contribute documentation changes or code, follow this! T
1. Fork the project.
2. Make your changes.
3. Make any documentation changes if necessary - if you add a new feature, it'll probably need documentation changes. See [here](https://clementtsang.github.io/bottom/nightly/contribution/documentation/) for tips on documentation.
4. Commit and create a pull request to merge into the `master` branch. **Please fill out the pull request template**.
4. Commit and create a pull request to merge into the `main` branch. **Please fill out the pull request template**.
5. Ask a maintainer to review your pull request.
- Check if the CI workflow passes. These consist of clippy lints, rustfmt checks, and basic tests. If you are a
first-time contributor, you may need to wait for a maintainer to let CI run.

View file

@ -5,7 +5,7 @@
A customizable cross-platform graphical process/system monitor for the terminal.<br />Supports Linux, macOS, and Windows. Inspired by <a href=https://github.com/aksakalli/gtop>gtop</a>, <a href=https://github.com/xxxserxxx/gotop>gotop</a>, and <a href=https://github.com/htop-dev/htop/>htop</a>.
</p>
[<img src="https://img.shields.io/github/actions/workflow/status/ClementTsang/bottom/ci.yml?branch=master&style=flat-square&logo=github" alt="CI status">](https://github.com/ClementTsang/bottom/actions?query=branch%3Amaster)
[<img src="https://img.shields.io/github/actions/workflow/status/ClementTsang/bottom/ci.yml?branch=main&style=flat-square&logo=github" alt="CI status">](https://github.com/ClementTsang/bottom/actions?query=branch%main)
[<img src="https://img.shields.io/crates/v/bottom.svg?style=flat-square" alt="crates.io link">](https://crates.io/crates/bottom)
[<img src="https://img.shields.io/badge/docs-stable-66c2a5?style=flat-square&labelColor=555555&logoColor=white" alt="Stable documentation">](https://clementtsang.github.io/bottom/stable)
[<img src="https://img.shields.io/badge/docs-nightly-88c0d0?style=flat-square&labelColor=555555&logoColor=white" alt="Nightly documentation">](https://clementtsang.github.io/bottom/nightly)
@ -311,7 +311,7 @@ curl -LO https://github.com/ClementTsang/bottom/archive/0.9.6.tar.gz
tar -xzvf 0.9.6.tar.gz
cargo install --path . --locked
# Option 2 - Clone from master and install manually
# Option 2 - Clone the repo and install manually
git clone https://github.com/ClementTsang/bottom
cd bottom
cargo install --path . --locked
@ -329,7 +329,7 @@ RUSTFLAGS="-C target-cpu=native" cargo install --path . --locked
You can also use the pre-built release binaries manually:
- [Latest stable release](https://github.com/ClementTsang/bottom/releases/latest), generated off of the release branch
- [Latest nightly release](https://github.com/ClementTsang/bottom/releases/tag/nightly), generated daily off of the master branch at 00:00 UTC
- [Latest nightly release](https://github.com/ClementTsang/bottom/releases/tag/nightly), generated off of the `main` branch at 00:00 UTC daily
To use, download and extract the binary that matches your system. You can then run by doing:

View file

@ -54,4 +54,4 @@ Each component of the layout accepts a `ratio` value. If this is not set, it def
Furthermore, you can have duplicate widgets.
For an example, look at the [default config](https://github.com/ClementTsang/bottom/blob/master/sample_configs/default_config.toml), which contains the default layout.
For an example, look at the [default config](https://github.com/ClementTsang/bottom/blob/main/sample_configs/default_config.toml), which contains the default layout.

View file

@ -10,7 +10,7 @@
## Overview
bottom manages its own binary builds for nightly and stable release purposes. The core build workflow is handled by [`build_releases.yml`](https://github.com/ClementTsang/bottom/blob/master/.github/workflows/build_releases.yml), called by a wrapper workflow for [nightly](https://github.com/ClementTsang/bottom/blob/master/.github/workflows/nightly.yml) and [stable](https://github.com/ClementTsang/bottom/blob/master/.github/workflows/deployment.yml) releases. Builds take place via GitHub Actions.
bottom manages its own binary builds for nightly and stable release purposes. The core build workflow is handled by [`build_releases.yml`](https://github.com/ClementTsang/bottom/blob/main/.github/workflows/build_releases.yml), called by a wrapper workflow for [nightly](https://github.com/ClementTsang/bottom/blob/main/.github/workflows/nightly.yml) and [stable](https://github.com/ClementTsang/bottom/blob/main/.github/workflows/deployment.yml) releases. Builds take place via GitHub Actions.
The main things built are:
@ -18,7 +18,7 @@ The main things built are:
- MSI installer for Windows
- `.deb` package for Debian and its derivatives
This documentation gives a high-level overview of the build process for each part. For the most up-to-date and detailed reference, definitely refer back to the [`build_releases.yml`](https://github.com/ClementTsang/bottom/blob/master/.github/workflows/build_releases.yml) file.
This documentation gives a high-level overview of the build process for each part. For the most up-to-date and detailed reference, definitely refer back to the [`build_releases.yml`](https://github.com/ClementTsang/bottom/blob/main/.github/workflows/build_releases.yml) file.
## Binaries

View file

@ -12,8 +12,8 @@
bottom currently has two main deploy processes to worry about:
- [Nightly](https://github.com/ClementTsang/bottom/blob/master/.github/workflows/nightly.yml): a daily (00:00 UTC) GitHub action to build binary/installer files, and upload them to the [nightly release](https://github.com/ClementTsang/bottom/releases/tag/nightly). It can also be triggered manually as either a proper nightly release or a mock release.
- [Stable](https://github.com/ClementTsang/bottom/blob/master/.github/workflows/deployment.yml): a stable deployment, triggered manually or upon creation of a valid tag. This is a GitHub action that builds binary/installer files and uploads them to a new GitHub release.
- [Nightly](https://github.com/ClementTsang/bottom/blob/main/.github/workflows/nightly.yml): a daily (00:00 UTC) GitHub action to build binary/installer files, and upload them to the [nightly release](https://github.com/ClementTsang/bottom/releases/tag/nightly). It can also be triggered manually as either a proper nightly release or a mock release.
- [Stable](https://github.com/ClementTsang/bottom/blob/main/.github/workflows/deployment.yml): a stable deployment, triggered manually or upon creation of a valid tag. This is a GitHub action that builds binary/installer files and uploads them to a new GitHub release.
Furthermore, this workflow does not handle the following deployments, which must be manually handled:

View file

@ -10,10 +10,10 @@
There are a few areas where documentation changes are often needed:
- The [`README.md`](https://github.com/ClementTsang/bottom/blob/master/README.md)
- The help menu inside of the application (located [here](https://github.com/ClementTsang/bottom/blob/master/src/constants.rs))
- The [`README.md`](https://github.com/ClementTsang/bottom/blob/main/README.md)
- The help menu inside of the application (located [here](https://github.com/ClementTsang/bottom/blob/main/src/constants.rs))
- The [extended documentation](https://clementtsang.github.io/bottom/nightly/) (here)
- The [`CHANGELOG.md`](https://github.com/ClementTsang/bottom/blob/master/CHANGELOG.md)
- The [`CHANGELOG.md`](https://github.com/ClementTsang/bottom/blob/main/CHANGELOG.md)
## How should I add/update documentation?
@ -23,20 +23,20 @@ There are a few areas where documentation changes are often needed:
<h3><code>README.md</code> or <code>CHANGELOG.md</code></h3>
For changes to [`README.md`](https://github.com/ClementTsang/bottom/blob/master/README.md) and [`CHANGELOG.md`](https://github.com/ClementTsang/bottom/blob/master/CHANGELOG.md), just follow the formatting provided and use any editor.
For changes to [`README.md`](https://github.com/ClementTsang/bottom/blob/main/README.md) and [`CHANGELOG.md`](https://github.com/ClementTsang/bottom/blob/main/CHANGELOG.md), just follow the formatting provided and use any editor.
Generally, changes to [`CHANGELOG.md`](https://github.com/ClementTsang/bottom/blob/master/CHANGELOG.md) will be handled
by a maintainer, and changes should follow the [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) format, as
well as link to the relevant PR or issue.
Generally, changes to [`CHANGELOG.md`](https://github.com/ClementTsang/bottom/blob/main/CHANGELOG.md) will be handled
by a maintainer, and the contents of the file should follow the [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
format, as well as link to the relevant PR or issues.
<h3>Help menu</h3>
For changes to the help menu, try to refer to the existing code within [`src/constants.rs`](https://github.com/ClementTsang/bottom/blob/master/src/constants.rs) on how the help menu is generated.
For changes to the help menu, try to refer to the existing code within [`src/constants.rs`](https://github.com/ClementTsang/bottom/blob/main/src/constants.rs) on how the help menu is generated.
<h3>Extended documentation</h3>
For changes to the extended documentation, you'll probably want at least Python 3.11 (older versions should be fine
though), [MkDocs](https://www.mkdocs.org/), [Material for MkDocs](https://squidfunk.github.io/mkdocs-material/),
For changes to the extended documentation, you'll probably want at least Python 3.11 (older and newer versions
should be fine), [MkDocs](https://www.mkdocs.org/), [Material for MkDocs](https://squidfunk.github.io/mkdocs-material/),
`mdx_truly_sane_lists`, and optionally [Mike](https://github.com/jimporter/mike) installed. These can help with
validating your changes locally.

View file

@ -26,7 +26,7 @@ The expected workflow for a pull request is:
1. Fork the project.
2. Make your changes.
3. Make any documentation changes if necessary - if you add a new feature, it'll probably need documentation changes. See [here](./documentation.md) for tips on documentation.
4. Commit and create a pull request to merge into the `master` branch. **Please fill out the pull request template**.
4. Commit and create a pull request to merge into the `main` branch. **Please fill out the pull request template**.
5. Ask a maintainer to review your pull request.
- Check if the CI workflow passes. These consist of clippy lints, rustfmt checks, and basic tests. If you are a
first-time contributor, you may need to wait for a maintainer to let CI run.

View file

@ -11,10 +11,10 @@ completion files for zsh, bash, fish, and Powershell, which you may want to also
process.
You can also find a nightly build in the [releases page](https://github.com/ClementTsang/bottom/releases), built every
day at 00:00 UTC off of the master branch.
day at 00:00 UTC off of the `main` branch.
In both cases, we use a combination of GitHub Actions and CirrusCI (mainly for FreeBSD and macOS M1) to create our
release binaries. [`build_releases.yml`](https://github.com/ClementTsang/bottom/blob/master/.github/workflows/build_releases.yml)
release binaries. [`build_releases.yml`](https://github.com/ClementTsang/bottom/blob/main/.github/workflows/build_releases.yml)
contains the GitHub Action workflow used to do both of these, if reference is needed.
## Building manually
@ -34,7 +34,7 @@ cargo build --release --locked
### Manpage and completion generation
bottom uses a [`build.rs`](https://github.com/ClementTsang/bottom/blob/master/build.rs) script to automatically generate
bottom uses a [`build.rs`](https://github.com/ClementTsang/bottom/blob/main/build.rs) script to automatically generate
a manpage and shell completions for the following shells:
- Bash
@ -54,13 +54,13 @@ This will automatically generate completion and manpage files in `target/tmp/bot
files, modify/delete either these files or set `BTM_GENERATE` to some other non-empty value to retrigger the build
script.
For more information, you may want to look at either the [`build.rs`](https://github.com/ClementTsang/bottom/blob/master/build.rs)
file or the [binary build CI workflow](https://github.com/ClementTsang/bottom/blob/master/.github/workflows/build_releases.yml).
For more information, you may want to look at either the [`build.rs`](https://github.com/ClementTsang/bottom/blob/main/build.rs)
file or the [binary build CI workflow](https://github.com/ClementTsang/bottom/blob/main/.github/workflows/build_releases.yml).
## Adding an installation source
Once you've finished your installation source, if you want to mention it in the main bottom repo, fork the repo and add
the installation method and any details to the [`README.md`](https://github.com/ClementTsang/bottom/blob/master/README.md)
the installation method and any details to the [`README.md`](https://github.com/ClementTsang/bottom/blob/main/README.md)
file under the [Installation](https://github.com/ClementTsang/bottom#installation) section, as well as a corresponding
table of contents entry. Once that's done, open a pull request - these will usually be approved of very quickly.

View file

@ -7,9 +7,9 @@ on the problem at the end of the day, _issues on unsupported platforms are likel
Unofficially supported platforms known to compile/work:
- FreeBSD
- Linux on ARMv7 and ARMv6 (tested to compile in [CI](https://github.com/ClementTsang/bottom/blob/master/.github/workflows/ci.yml))
- Linux on PowerPC 64 LE (tested to compile in [CI](https://github.com/ClementTsang/bottom/blob/master/.github/workflows/ci.yml))
- Linux on an RISC-V (tested to compile in [CI](https://github.com/ClementTsang/bottom/blob/master/.github/workflows/ci.yml), tested to run on an [Allwinner D1 Nezha](https://github.com/ClementTsang/bottom/issues/564))
- Linux on ARMv7 and ARMv6 (tested to compile in [CI](https://github.com/ClementTsang/bottom/blob/main/.github/workflows/ci.yml))
- Linux on PowerPC 64 LE (tested to compile in [CI](https://github.com/ClementTsang/bottom/blob/main/.github/workflows/ci.yml))
- Linux on an RISC-V (tested to compile in [CI](https://github.com/ClementTsang/bottom/blob/main/.github/workflows/ci.yml), tested to run on an [Allwinner D1 Nezha](https://github.com/ClementTsang/bottom/issues/564))
## Known problems

View file

@ -106,7 +106,7 @@ If your configuration files aren't working, here are a few things to try:
### Check the formatting
It may be handy to refer to the automatically generated config files or the [sample configuration files](https://github.com/ClementTsang/bottom/tree/master/sample_configs).
It may be handy to refer to the automatically generated config files or the [sample configuration files](https://github.com/ClementTsang/bottom/tree/main/sample_configs).
The config files also follow the [TOML](https://toml.io/en/) format.
Also make sure your config options are under the right table - for example, to set your temperature type, you must set it under the `[flags]` table:

View file

@ -8,7 +8,7 @@ docs_dir: "content/"
# Project information
repo_name: ClementTsang/bottom
repo_url: https://github.com/ClementTsang/bottom
edit_uri: "edit/master/docs/content/"
edit_uri: "edit/main/docs/content/"
# Theming
theme:

View file

@ -27,7 +27,7 @@ This is a nuspec. It mostly adheres to https://docs.nuget.org/create/Nuspec-Refe
<title>bottom</title>
<authors>Clement Tsang</authors>
<projectUrl>https://github.com/ClementTsang/bottom</projectUrl>
<licenseUrl>https://github.com/ClementTsang/bottom/blob/master/LICENSE</licenseUrl>
<licenseUrl>https://github.com/ClementTsang/bottom/blob/main/LICENSE</licenseUrl>
<requireLicenseAcceptance>true</requireLicenseAcceptance>
<projectSourceUrl>https://github.com/ClementTsang/bottom</projectSourceUrl>
<packageSourceUrl>https://github.com/ClementTsang/choco-bottom</packageSourceUrl>
@ -41,7 +41,7 @@ This is a nuspec. It mostly adheres to https://docs.nuget.org/create/Nuspec-Refe
**Usage**
To use, run `btm` in a terminal.
For more [documentation and usage](https://github.com/ClementTsang/bottom/blob/master/README.md), see the [official repo](https://github.com/ClementTsang/bottom).
For more documentation and usage information, go to the [official repo](https://github.com/ClementTsang/bottom).
Please report any issues with the Chocolatey package [here](https://github.com/ClementTsang/choco-bottom).