cargo_auto_github_lib

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

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:

cargo_auto_github_lib="0.1.*"

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

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(
        &github_owner,
        &repo_name,
        &tag_name_version,
        &release_name,
        branch,
        &body_md_text,
    ));

    //...

    // upload asset
    cgl::github_api_upload_asset_to_release(
        &github_client,
        &github_owner,
        &repo_name,
        &release_id,
        &tar_name,
    );
}

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.

Functions

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! 🍻

//bestia.dev
//github.com/bestia-dev
//bestiadev.substack.com
//youtube.com/@bestia-dev-tutorials