12 releases (stable)
1.1.8 | Apr 30, 2024 |
---|---|
1.1.6 | Apr 23, 2024 |
0.1.34 | Apr 16, 2024 |
0.1.24 | May 31, 2023 |
0.1.5 |
|
#61 in Build Utils
41KB
320 lines
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 Githubauto_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
Dependencies
~20–34MB
~598K SLoC