created_at2021-08-27 08:15:59.869433
updated_at2024-04-30 21:47:48.079427
descriptionLibrary for cargo-auto `automation tasks written in rust language` with functions for GitHub.
size41,624 (bestia-dev)




Library for cargo-auto automation tasks written in rust language with functions for GitHub.
version: 1.1.8 date: 2024-04-30 author: repository: GitHub

maintained ready-for-use rust cargo-auto

Lines in Rust code Lines in Doc comments Lines in Comments Lines in examples Lines in tests Documentation crev reviews License Rust Hits

Hashtags: #rustlang #buildtool #developmenttool #github
My projects on Github are more like a tutorial than a finished product: bestia-dev tutorials.

Try it

In your rust project root directory (where the Cargo.toml is)
first install cargo-auto and generate a new helper project:

cargo install cargo-auto
cargo auto new

In a new editor open the generated directory automation_tasks_rs as an independent rust project. There is already this dependency in Cargo.toml:


Preview the code and observe all the auto_github_* functions from cargo_auto_github_lib.

fn task_github_new_release() {
    // ...

    let github_client = crate::github_mod::GitHubClient::new();
    let json_value = github_client.send_to_github_api(cgl::github_api_create_new_release(


    // upload asset

You need to have a GitHub PAT (personal access secret_token).

Run (in your main rust project):

cargo auto release
cargo auto github_new_release

With a little luck, it will create a new release in github.


All the functions have extensive hep/docs to describe how they work.
It is nice when you use a code editor with IntelliSense like VSCode.
Here is a list of some of them:

  • auto_github_create_new_release() - creates new release on Github
  • auto_github_upload_asset_to_release() - add asset to the github release

GitHub API secret_token

The GitHub API secret_token is a secret just like a password. Maybe even greater.
With this API secret_token, a maleficent actor can change basically anything in your GitHub account. You don't want that.

How to protect this secret?
Ok, there are some basic recommendations:

  • HTTPS is a no-brainer. Never use HTTP ever again. It is plain text over the wire.
  • Expire the secret_token frequently, so old secret_tokens are of no use
  • Never store the secret_token in a file as plain text
  • Plain text inside env vars can also be accessed from malware
  • give the least permission/authorization to the API secret_token

But the true problem arises at the moment when you want to use the secret_token. How to trust the code you are giving the secret_token to?
Probably the best is that this code is written by you or that you have complete control over it. This makes very cumbersome the use of libraries/crates. You cannot trust them by default. However, it is impossible to avoid trust in low-level crates/libraries.

Open-source and free as a beer

My open-source projects are free as a beer (MIT license).
I just love programming.
But I need also to drink. If you find my projects and tutorials helpful, please buy me a beer by donating to my PayPal.
You know the price of a beer in your local bar ;-)
So I can drink a free beer for your health :-)
Na zdravje! Alla salute! Prost! Nazdravlje! 🍻


Commit count: 93

cargo fmt