Make a note of release sizes in the nightly/deploy scripts. This is mostly just in case I need to refer to it in the future (mainly for nightly, as the actual generated files are overwritten daily).
Disables incremental compilation and debug symbols in CI and other related workflows, since they're not used there at all. Also forces --locked as needed.
This changes various as_ref() calls as needed in order for bottom to successfully build in Rust beta 1.61, as they were causing type inference issues. These calls were either removed or changed to an alternative that does build (e.g. as_slice()).
Functionally, there should be no change.
For context, see:
- https://github.com/ClementTsang/bottom/issues/708
- https://github.com/rust-lang/rust/issues/96074
Adds the asset for the manpage to cargo deb config. Also moves the generated manpage file to a .1.gz file. Also, moves back to a build script since that was causing some issues for the automatic Cargo.toml fields detection for manpage and completion generation.
To prevent compilation from happening every time, and only in CI, we use an env var to avoid generation steps.
Adds manpage generation to the build process, as well as following the xtask concept of adding additional build scripts that only need to run on deploy/nightly as opposed to `build.rs`. Note this doesn't follow the recommended method of using workplaces because I don't really want to shift the entire repo structure just for this.
More on xtask: https://github.com/matklad/cargo-xtask
Adds an indicator in the form of `$version (stable)` to make it easier to see which is the most recent stable version.
This is done via CI and mike:
1. Set the previous title to just `$version`. We can get this value by `mike list stable` and grepping for valid version tags (otherwise this might have issues with `$version (stable)`).
2. Deploy `$new_version` and alias to stable.
3. Update the `$new_version` to have a new title of `$new_version (stable)`.
This was causing issues with the choco workflow in another repo since
the name was incorrect; I've decided to also rename the template for
consistency.
Due to how matrices work with if/skipping, it seems like this ugly hack is the only way to skip CI based on the files updated without clogging the PR pipeline.
In a similar vein to #590, we only create a release after the entire pipeline is completed and succeeds. Also fixes some incorrect job names and adds some "/'s" after directory names in the nightly pipeline.
Changes the nightly build workflow to delete/create a new release *only* if the entire build process passes. This avoids a potential case of a nightly build failing but having overwritten the old one, which has happened before.
After this change lands, similar changes will probably be made to the deployment script for releases.
Adds a `ProductCode`, `Scope`, and `Commands` field to the template, as well as additional changes to the deploy process to determine + fill in the `ProductCode` automatically.
Seems like we have a few too many tests that aren't really needed for just asserting CI is passing.
The goal for CI (IMO) is just to ensure things still build on the various supported platforms after changes are made. However, there were a few tested scenarios like Windows GNU or musl which I feel weren't really too important in this regard, and added extra time to an already long CI process.
Commented out the following tests since there aren't any architecture-specific features that require running these in addition to other already-existing tests:
- Windows GNU
- Linux musl (both x86 and x86_64)
Of course, should we add changes that directly affect these architectures, then we should add the tests back.
A large migration of documentation over to mkdocs, and some rewrites. Some stuff (install information, basic supported systems, contributors, thanks) are still staying in README.md, and CONTRIBUTING.md is essentially duplicated right now. However, stuff like configuration and key/mouse bindings are now moved to mkdocs.
Some parts are still a bit WIP - it is definitely not done (documentation never seems to be...). However, it should be "good enough" for now, and I'm much happier working with the documentation in this form than trying to scroll through a giant endless README.md file. It also works much better for adding new documentation.
Since we're moving all 16.04 ubuntu builds to 18.04, I thought this would be a good idea in case anyone needed it.
Not sure if we should have just made ALL Linux builds use the older Linux container... for now I'll just make one extra build.
Rewrite of the y-axis labeling and scaling for the network widget, along with more customization. This still has one step to be optimized (cache results so we don't have to recalculate the legend each time), but will be done in another PR for sake of this one being too large already.
Furthermore, this change adds linear interpolation at the 0 point in the case a data point shoots too far back - this seems to have lead to ugly gaps to the left of graphs in some cases, because the left hand limit was not big enough for the data point. We address this by grabbing values just outside the time range and linearly interpolating at the leftmost limit. This affects all graph widgets (CPU, mem, network).
This can be optimized, and will hopefully be prior to release in a separate change.
