47 Commits

Author SHA1 Message Date
daf9ec6ae6 Update changelog for 3.0.0-1 release 2025-07-22 09:54:41 -05:00
fc44129039 Rediff patches 2025-07-22 09:54:05 -05:00
a88e44ab97 Add new upstream dependency to debian/control
Also sort the dependencies alphabetically.
2025-07-22 09:52:42 -05:00
17165a58bb Merge tag 'v3.0.0' into deb/bookworm 2025-07-22 09:52:29 -05:00
641efc3bf7 Update automation workflow with new CLI args
All checks were successful
/ Compile and upload a release build (release) Successful in 1m10s
2025-07-22 09:41:54 -05:00
144fba5373 Bump crate version to v3.0.0
Some checks failed
/ Compile and upload a release build (release) Failing after 49s
2025-07-21 16:37:37 -05:00
7f35b808e5 Lint and format 2025-07-21 16:37:14 -05:00
00edaf87ce Mark the file-format and search-path conf sections
There are two concepts here and that should be more clearly indicated.

Introduce the file format with some examples, then talk about where
those files are found.
2025-07-21 16:21:10 -05:00
250140a954 Rephrase the all-projects setting introduction 2025-07-21 16:20:48 -05:00
b290a8b1d6 Drop the "no-repo" comment in TOML example
It's not relevant to the example and might confuse readers as a result.
2025-07-21 16:18:44 -05:00
b952e40060 Revise explanation of --project option
I need to introduce the idea that "projects" are actually file paths,
and that these paths are the keys for the key-value stores that are the
config files.

...but without saying "HashMap" because that's really an implementation
detail.
2025-07-21 16:14:47 -05:00
4b9257a9a7 Rename remaining CLI arg sections
The previous text was pretty ugly and not particularly useful to catch
the eye when looking for relevant sections.
2025-07-21 16:13:46 -05:00
d34eda77dc Delete the old CLI option sections 2025-07-21 16:12:56 -05:00
3315c18ed2 New 'authentication' section
The auth tokens can now be loaded from the config files, so I need to
mention that.

I took the opportunity to revise the explanation of when auth is
required. Now it has a more obvious example of how it depends on
instance configuration.
2025-07-21 16:09:12 -05:00
0e7bca80cb Create a short, complete explanation of req. info.
I don't need to have nearly so much information explaining how to use
optional command line arguments. The quirk about the "repo" needing to
be a URL fragment somewhat justified the extra explanation, but that's
gone now.

Instead, a short, up-front section stating which bits are required and
where the program will try to get them.
2025-07-21 16:08:08 -05:00
5bd2862498 Update usage printout 2025-07-21 15:47:23 -05:00
333636b524 Revise help text for CLI "--project" arg 2025-07-21 14:57:18 -05:00
e954a2b09a Drop notice about CLI not having "repo" & "owner" 2025-07-21 14:54:16 -05:00
da8f008f1a Use current-dir as final fallback repo name
It all falls into place! I had been dreading doing this bit, but after
updating the usage guide I realized the CLI args should be split, too.
Which finally means that I can just glue on the PWD name as a final
fallback for the repo name.

Try the args, then the config file(s), then PWD. If nothing works, the
user is in a world of hurt. Bail out.
2025-07-21 14:48:30 -05:00
7c0966be30 Split the owner and repo args apart in CLI parser 2025-07-21 14:21:13 -05:00
c1019afa7a Write configuration guide in the README 2025-07-21 14:04:04 -05:00
1a619d7bb4 Update CLI usage guide, add project lookup guide
There's a new inconsistency, however. The previous URL and FQRN
arguments are no longer mandatory but their description makes it seem
as though they are.
2025-07-21 14:04:01 -05:00
fc0d1b569c Add a project path CLI option 2025-07-21 11:56:20 -05:00
8cfc6605c9 Mark pre-release 3.0.0-alpha.1
The configuration file loading is complete and seems to work the way I
expect. I still need to do an improved project guessing system, and it
would be smart to allow the user to explicitly enter a config file to
use.
2025-07-21 10:58:37 -05:00
0e814b86a1 Fix some clippy lints 2025-07-21 10:52:20 -05:00
0e3aa16e00 Another autoformat 2025-07-20 17:36:49 -05:00
04dd333d72 Fix: use default "[all]" if one isn't present
Same thing as the previous commit, but for the "[all]" table.
2025-07-20 17:33:55 -05:00
13ef1d25eb Fix: use empty PartialConfig if proj conf missing
If there is no project-specific configuration, use a default one
instead. It still needs to be merged with the "[all]" one, assuming that
exists.

Now to do the same thing for the all-table.
2025-07-20 17:32:11 -05:00
56b0580a9a Add docstring for PartialConfig::try_from()
I started to replace this with an infallible `try()` implementation
before realizing that this exists specifically to filter out the
no-such-table result. That isn't an error *in this context*, which is
what the try_from() is doing for me.
2025-07-20 17:23:44 -05:00
46d8618e74 Fix config unit tests: project path is set!
The project path value gets set as a side-effect of loading the named
configuration table. Which... actually means this information isn't
important. I know it going in, and I know it coming out. I think the
real fix is to delete the field.
2025-07-20 17:23:15 -05:00
73363718c3 Add test for skipping unavailable conf files
Missing config files aren't an error. Make sure there isn't some kind of
early return logic that emits broken data.
2025-07-20 16:06:25 -05:00
f9673b715f Update changelog for 2.2.0-2 release 2025-07-13 17:00:26 -05:00
820a9daaed Fix typo in copyright comment 2025-07-13 16:56:00 -05:00
8d71b81271 Fix: "Source:" URL in debian/copyright
That's what I get for copying other peoples' homework. I should have
used one of the `dh*` commands to build out the packaging boilerplate.
Oh well.
2025-07-13 16:51:22 -05:00
17bde93259 Update changelog for 2.2.0-1 release 2025-07-04 10:11:04 -05:00
cdb312fe61 Add the new dependencies to debian/control
Debian's package machinery also needs to know about these things, so
throw them into the control file.
2025-07-04 10:07:47 -05:00
cfaa0ceb3f Lift the empty-body string outside the let-if
Patch the string reference lifetime issue, and rediff the other patch
while we're at it.
2025-07-04 09:57:16 -05:00
c0a0181074 Merge tag 'v2.2.0' into deb/bookworm 2025-07-04 09:43:25 -05:00
bbae6b4395 Update changelog for 2.1.0-1 release 2025-06-12 17:51:23 -05:00
2c03c5ba4d Merge tag 'v2.1.0' into deb/bookworm
Hotfix for Attachment decode error
2025-06-12 17:48:09 -05:00
6a9ec25d1a Update changelog for 2.0.0-1 release 2025-06-12 16:28:43 -05:00
395ce8a804 Rediff patches
Drop 0002-Use-pre-Rust-1.81-compatible-file-exists-test.patch: <REASON>
2025-06-12 16:24:48 -05:00
616be020f0 Merge tag 'v2.0.0' into deb/bookworm
Mark release for v2

Now with better error diagnostics!... better... They're still not great.
2025-06-12 16:22:33 -05:00
324c7e67a7 Re-assign v1.0.0-1 to 'unstable'
I should have done this before publishing the build, but it's too late
now. Instead, I'll update it here and continue forward with gbp-dch to
help generate more correct changelogs.
2025-06-12 12:55:16 -05:00
984974c240 Update debian/gbp.conf to use new branch name
I'm switching to use nested tags for the packaging branches. I want to
have a deb/bookworm and a deb/experimental branch. The gbp-pq tool
already seems to do this, so I'll follow it's lead.
2025-06-12 12:50:48 -05:00
4c05749d02 Rediff patches
Add 0002-Use-pre-Rust-1.81-compatible-file-exists-test.patch: <REASON>
Add 0001-Rust-edition-downgrade-to-2021.patch: <REASON>
2025-06-06 19:22:09 -05:00
c0e6c5d89d Create Debian packaging files 2025-06-06 19:19:39 -05:00
16 changed files with 486 additions and 59 deletions

View File

@@ -22,7 +22,9 @@ jobs:
- name: Upload the program (using itself!)
run: >
target/release/gt-tool-${{ github.ref_name }}-$(arch)
-u ${{ vars.DEST_GITEA }} -r ${{ vars.DEST_REPO }}
-u ${{ vars.DEST_GITEA }}
-o ${{ vars.DEST_OWNER }}
-r ${{ vars.DEST_REPO }}
upload-release
"${{ github.ref_name }}"
target/release/gt-tool-${{ github.ref_name }}-$(arch)

View File

@@ -1,6 +1,6 @@
[package]
name = "gt-tool"
version = "2.2.0"
version = "3.0.0"
edition = "2024"
[dependencies]

111
README.md
View File

@@ -5,7 +5,7 @@ CLI tools for interacting with the Gitea API. Use interactively to talk to your
## Usage
```txt
Usage: gt-tools --url <GITEA_URL> --repo <REPO> <COMMAND>
Usage: gt-tool [OPTIONS] <COMMAND>
Commands:
list-releases
@@ -14,35 +14,52 @@ Commands:
help Print this message or the help of the given subcommand(s)
Options:
-u, --url <GITEA_URL> [env: GTTOOL_GITEA_URL=]
-r, --repo <REPO> [env: GTTOOL_FQRN=]
-h, --help Print help
-V, --version Print version
-u, --url <GITEA_URL> [env: GTTOOL_GITEA_URL=]
-o, --owner <OWNER> [env: GTTOOL_OWNER=]
-r, --repo <REPO> [env: GTTOOL_REPO=]
-p, --project <PROJECT> Path to project (relative or absolute). Used to override configuration selection.
-h, --help Print help
-V, --version Print version
```
### Required Information
To function, this program requires knowledge of these items:
- Gitea URL
- Owner of repository
- Repository name
This info will be gathered from these locations, in order of priority:
1. CLI argument
2. Environment variable
3. Configuration files
It's worth noting that the "owner" is the entity that controls the repo on the Gitea instance. This will be the first part of the route in the URL: `http://demo.gitea.com/{owner}`.
Likewise, the "repo" is what ever the Gitea instance thinks it's called -- which doesn't have to match anyone's local copy! It will be the second part of the route in the URL: `http://demo.gitea.com/{owner}/{repo}`.
### Authentication
Authentication is token-based via environment variable `RELEASE_KEY_GITEA`.
Authentication is token-based. There is no CLI option to prevent the token from appearing in any command logs.
Ensure your token has the appropriate access for your usage. This depends on what you're doing and how your Gitea instance is configured, so you'll have to figure it out for yourself.
In order of priority, the token is loaded from:
Most likely, you will need a token with "repository: read-and-write" permissions. See Gitea's documentation on [token scopes](https://docs.gitea.com/development/oauth2-provider#scopes) for more.
1. The environment variable `RELEASE_KEY_GITEA`
2. Config files, key `token`
### `<GITEA_URL>`:
Whether or not it is required depends on how your Gitea instance and the repositories inside are configured. For example, a default Gitea configuration will allow unauthenticated users to see public repositories but not make any changes. This means no token is required to run `gt-tool list-releases`, while `gt-tool upload-release` *will* require a token.
The Gitea server URL must be provided with `--url` or `-u` on the command line, or via the environment variable `GTTOOL_GITEA_URL`. Use the base URL for your Gitea instance.
For details, see Gitea's documentation on [token scopes](https://docs.gitea.com/development/oauth2-provider#scopes).
E.g.: Using the Gitea org's demo instance, it would be: `--url "https://demo.gitea.com/"`
### The `--project` option
### `<REPO>`:
Settings retrieved from config files are selected based on the project's path. By default, the current directory will be used. In case that guess is incorrect, this option can be specified with another path.
The repository name must be provided with `--repo` or `-u` on the command line, or via the environment variable `GTTOOL_GITEA_FQRN` ("fully qualified repo name"). Use the format `<owner>/<repo>`, which is the route immediately following the GITEA_URL base. This is how GitHub and Gitea identify repos in the URL, and how Golang locates it's modules, so this tool does the same.
See [configuration](#configuration) for details on format and file locations.
E.g.: `--repo "go-gitea/gitea"` would name the Gitea repo belonging to the go-gitea organization.
### `<COMMAND>`:
One of these, defaults to `help`:
### Commands:
| Command | Description |
|-|-|
@@ -51,3 +68,61 @@ One of these, defaults to `help`:
| upload-release | Uploads one-or-more files to an existing release, identified by it's tag name. |
| help | prints the help text (the usage summary above). |
## Configuration
Instead of specifying everything on the command line every single run, some TOML files can be used to persist project settings.
> Exporting some environment variables would be similar, but that would be *more* annoying when working on multiple projects. One would have to constantly re-export the settings or use two shells. But then there's the issue of losing track of which shell has which settings.
### File Format
Settings are retrieved from a table named the same as the project's path on disk. For example, gt_tool itself could have an entry as follows:
```toml
["/home/robert/projects/gt-tool"]
gitea_url = "https://demo.gitea.com/"
owner = "dummy"
repo = "gt-tool"
token = "fake-token"
```
Sometimes one may want to apply a setting to all projects. For this, they can use the special `[all]` table.
```toml
[all]
gitea_url = "https://demo.gitea.com/"
```
Since the more-specific settings are preferred, these can be combined to have an override effect.
```toml
[all]
gitea_url = "https://demo.gitea.com/"
owner = "robert"
token = "fake-token"
# Override Gitea target so I can test my uploads privately.
["/home/robert/projects/gt-tool"]
gitea_url = "http://localhost:3000"
repo = "gt-tool"
```
### Search Paths
Similar to how unspecified project settings will fall back to those in the "`[all]`" table, whole files will fall back to other, lower priority files.
1. First, each dir in `$XDG_CONFIG_DIRS` is scanned for a `gt-tool.toml` file.
2. Then, `/etc/gt-tool.toml`.
> All config files **MUST** be named named `gt-tool.toml`.
### Recognized Keys
| Key | Description |
|-|-|
| gitea_url | URL of the Gitea server. Same as `-u`, `--url`, and `$GTTOOL_GITEA_URL`. |
| owner | Owner of the repository (individual, or organization). Combined with "repo" key to produce the fully-qualified-repo-name. Front-half of `-r`, `--repo`, and `$GTTOOL_FQRN` |
| repo | Name of the repository on the Gitea server. Combined with "owner" key to produce the fully-qualified-repo-name. Back-half of `-r`, `--repo`, and `$GTTOOL_FQRN` |
| token | Gitea auth token, exactly the same as `$RELEASE_KEY_GITEA` |
Additional keys are quietly ignored. The config loading is done by querying a HashMap, so anything not touched doesn't get inspected. The only requirements are that the file is valid TOML, and that these keys are all strings.h

121
debian/changelog vendored Normal file
View File

@@ -0,0 +1,121 @@
gt-tool (3.0.0-1) unstable; urgency=medium
* Make the README title singular
* Add a Cargo.toml & Git tag version comparison
* Scaffold the new config module
* Add property-get utility function
* Add a get-table util function
* Util fn's can use anything that impl's ToString
* Util to get sometimes-empty config property
* Add partial- and whole- config structs
* Prototype load-config function
* Put the per-project test expects in for lconf()
* Finish `fn lconf()`. Project-specific vals load
* Create-and-assign struct to whole.all
* Use the get_table util to extract "[all]" table
* Extract PartCfg readers to a try_from impl
* Add a builder-pattern proj-path setter, for flavor
* Assert empty conf str is an error, TODO: semantics
* Rename the config-string-reading function
* Externalize the test table
* Remove some debug prints
* Signature & tests for fn load_from_file()
* Implement the load_from_file function
* "Merge" method on PartialConfig
* Complete the public `get_config()` function
* Pass in search files rather than generating them
* Make default search paths available as util fn
* Remove `WholeFile` struct & anything that uses it
* Autoformat
* Cargo clippy fixes
* Delete a now-solved FIXME comment
* Make the URL and Repo FQRN CLI args optional
* Wire in the conf file loading, assume PWD project
* Add more unit tests for the config loader
* Add test for skipping unavailable conf files
* Fix config unit tests: project path is set!
* Add docstring for PartialConfig::try_from()
* Fix: use empty PartialConfig if proj conf missing
* Fix: use default "[all]" if one isn't present
* Another autoformat
* Fix some clippy lints
* Mark pre-release 3.0.0-alpha.1
* Add a project path CLI option
* Update CLI usage guide, add project lookup guide
* Write configuration guide in the README
* Split the owner and repo args apart in CLI parser
* Use current-dir as final fallback repo name
* Drop notice about CLI not having "repo" & "owner"
* Revise help text for CLI "--project" arg
* Update usage printout
* Create a short, complete explanation of req. info.
* New 'authentication' section
* Delete the old CLI option sections
* Rename remaining CLI arg sections
* Revise explanation of `--project` option
* Drop the "no-repo" comment in TOML example
* Rephrase the all-projects setting introduction
* Mark the file-format and search-path conf sections
* Lint and format
* Bump crate version to v3.0.0
* Update automation workflow with new CLI args
* Add new upstream dependency to debian/control
* Rediff patches
-- Robert Garrett <robertgarrett404@gmail.com> Tue, 22 Jul 2025 09:54:28 -0500
gt-tool (2.2.0-2) unstable; urgency=medium
* Fix: "Source:" URL in debian/copyright
* Fix typo in copyright comment
-- Robert Garrett <robertgarrett404@gmail.com> Sun, 13 Jul 2025 16:59:25 -0500
gt-tool (2.2.0-1) unstable; urgency=medium
* Basic impl Display for the Release struct
* Print releases in reverse order for easier reading
* Colorize the output!
* Remove trailing newline in Release item printout
* Galaxy-brained newline intersperse function
* Change to free-fn intersperse for stdlib compat
* `Release.colorized()`, not std::fmt::Display
* Address most of the cargo-clippy lints
* Prefix unused variables to quiet the linter
* Autoformat
* Oops, missed one
* Bump to v2.2.0
* Lift the empty-body string outside the let-if
* Add the new dependencies to debian/control
-- Robert Garrett <robertgarrett404@gmail.com> Fri, 04 Jul 2025 10:10:54 -0500
gt-tool (2.1.0-1) unstable; urgency=medium
* Fix: incorrect field names for `Attachment`
-- Robert Garrett <robertgarrett404@gmail.com> Thu, 12 Jun 2025 17:51:12 -0500
gt-tool (2.0.0-1) unstable; urgency=medium
* Interrogate list_releases result more closely
* Interrogate create_release result more closely
* Drop unused imports
* "Fix" the test case
* Interrogate create_release_attachment result
* Fold client-error-decode into a util function
* Add `Attachment` struct, new iface for create-rel
* Update main.rs to use new attachment iface
* Delete the unit tests
* ... and the unit testing notes in README.md
* Drop unused import in api/release.rs
* Use pre Rust 1.81 compatible file-exists test
* Rediff patches
-- Robert Garrett <robertgarrett404@gmail.com> Thu, 12 Jun 2025 16:28:18 -0500
gt-tool (1.0.0-1) unstable; urgency=low
* Experimental release.
-- Robert Garrett <robertgarrett404@gmail.com> Sun, 1 Jun 2025 16:05:00 -0500

33
debian/control vendored Normal file
View File

@@ -0,0 +1,33 @@
Source: gt-tool
Maintainer: Robert Garrett <robertgarrett404@gmail.com>
Section: misc
Priority: optional
Standards-Version: 4.6.2
Build-Depends:
debhelper-compat (= 13),
dh-cargo,
librust-clap-dev,
librust-colored-dev,
librust-itertools-dev,
librust-reqwest-dev,
librust-serde-dev,
librust-tokio-dev,
librust-toml-dev,
Homepage: https://git.gelvin.dev/robert/gt-tool
Vcs-Git: https://git.gelvin.dev/robert/gt-tool
Vcs-Browser: https://git.gelvin.dev/robert/gt-tool
Rules-Requires-Root: no
Package: gt-tool
Architecture: any
Depends:
${misc:Depends},
${shlibs:Depends},
Description: CLI tools for interacting with the Gitea API.
Use interactively to talk to your Gitea instance, or automatically via a CI/CD
pipeline. Currently supports:
.
- showing the Releases for a project
- creating a new Release for a project
- attaching files to a release

43
debian/copyright vendored Normal file
View File

@@ -0,0 +1,43 @@
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: gt-tools
Upstream-Contact: Robert Garrett <robertgarrett404@gmail.com>
Source: https://git.gelvin.dev/robert/gt-tool
Files: *
Copyright: 2025 Robert Garrett <robertgarrett404@gmail.com>
License: GPL-3+
Files: debian/*
Copyright: 2025 Robert Garrett <robertgarrett404@gmail.com>
License: GPL-3+
Files: debian/rules
Copyright:
Johannes Schauer Marin Rodrigues <josch@debian.org>
2025 Robert Garrett <robertgarrett404@gmail.com>
License: GPL-3+
Comment:
The debian/rules file is lifted directly from the tuigreet package. It was
linked in the Debian Rust Team Book as a pretty simple example package. The
only change I've made is to remove the documentation generation target.
.
https://salsa.debian.org/debian/tuigreet/-/blob/master/debian/rules?ref_type=heads
License: GPL-3+
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
.
It is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License for more details.
.
You should have received a copy of the GNU General Public License
along with it. If not, see <http://www.gnu.org/licenses/>.
.
On Debian systems, the full text of the GNU General Public License version 3
can be found in the file /usr/share/common-licenses/GPL-3.

6
debian/gbp.conf vendored Normal file
View File

@@ -0,0 +1,6 @@
[DEFAULT]
compression = xz
compression-level = 9
upstream-tag = v%(version)s
debian-branch = deb/bookworm

View File

@@ -0,0 +1,23 @@
From: Robert Garrett <robertgarrett404@gmail.com>
Date: Sun, 1 Jun 2025 17:59:20 -0500
Subject: Rust edition downgrade to 2021
Debian Bookworm uses Rust 1.63 which only supports up to the 2021
edition.
---
Cargo.toml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Cargo.toml b/Cargo.toml
index 39341a1..4ec2031 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -1,7 +1,7 @@
[package]
name = "gt-tool"
version = "3.0.0"
-edition = "2024"
+edition = "2021"
[dependencies]
clap = { version = "4.0.7", features = ["derive", "env"] }

View File

@@ -0,0 +1,39 @@
From: Robert Garrett <robertgarrett404@gmail.com>
Date: Fri, 4 Jul 2025 09:36:52 -0500
Subject: Lift the empty-body string outside the let-if
The if-else block that selects between the body of the Release or a
placeholder is returning references to variables that only exist
*inside* the body of the if-else blocks. Newer Rust versions seem to
understand the intent and do The Right Thing anyway (or they have some
other rule for how if-else block scopes work).
Manually lifting the variable to an outer scope resolves the problem.
---
src/structs/release.rs | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/structs/release.rs b/src/structs/release.rs
index 9ed537e..3c4a434 100644
--- a/src/structs/release.rs
+++ b/src/structs/release.rs
@@ -1,3 +1,5 @@
+use std::io::empty;
+
use colored::Colorize;
use serde::{Deserialize, Serialize};
@@ -27,10 +29,11 @@ impl Release {
let published = "Published:".bright_green();
let created = "Created:".green().dimmed();
let author = "Author:".blue();
+ let empty_body = String::from("(empty body)").dimmed();
let body = if !self.body.is_empty() {
- &self.body.white()
+ self.body.white()
} else {
- &String::from("(empty body)").dimmed()
+ empty_body
};
format!(

2
debian/patches/series vendored Normal file
View File

@@ -0,0 +1,2 @@
0001-Rust-edition-downgrade-to-2021.patch
0002-Lift-the-empty-body-string-outside-the-let-if.patch

26
debian/rules vendored Executable file
View File

@@ -0,0 +1,26 @@
#!/usr/bin/make -f
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/default.mk
include /usr/share/rustc/architecture.mk
export DEB_HOST_RUST_TYPE
export PATH:=/usr/share/cargo/bin:$(PATH)
export CARGO=/usr/share/cargo/bin/cargo
export CARGO_HOME=$(CURDIR)/debian/cargo_home
export CARGO_REGISTRY=$(CURDIR)/debian/cargo_registry
export DEB_CARGO_CRATE=$(DEB_SOURCE)_$(DEB_VERSION_UPSTREAM)
%:
dh $@ --buildsystem=cargo
execute_after_dh_auto_clean:
$(CARGO) clean
rm -rf $(CARGO_HOME)
rm -rf $(CARGO_REGISTRY)
rm -f debian/cargo-checksum.json
execute_before_dh_auto_configure:
$(CARGO) prepare-debian $(CARGO_REGISTRY) --link-from-system
rm -f Cargo.lock
touch debian/cargo-checksum.json

1
debian/source/format vendored Normal file
View File

@@ -0,0 +1 @@
3.0 (quilt)

View File

@@ -5,8 +5,16 @@ use clap::{Parser, Subcommand};
pub struct Args {
#[arg(short = 'u', long = "url", env = "GTTOOL_GITEA_URL")]
pub gitea_url: Option<String>,
#[arg(short = 'r', long = "repo", env = "GTTOOL_FQRN")]
#[arg(short = 'o', long = "owner", env = "GTTOOL_OWNER")]
pub owner: Option<String>,
#[arg(short = 'r', long = "repo", env = "GTTOOL_REPO")]
pub repo: Option<String>,
#[arg(
short = 'p',
long = "project",
help = "Path to project (relative or absolute). Used to override configuration selection."
)]
pub project: Option<String>,
#[command(subcommand)]
pub command: Commands,

View File

@@ -105,16 +105,20 @@ pub fn get_config(
// 2. Get table
get_table(cfg_table, project)
// 3. convert to PartialConfig
// 3a. convert to PartialConfig
.and_then(PartialConfig::try_from)
// 3b. or default, if the table couldn't be found.
.or(Ok(PartialConfig::default()))
// 4. assemble a 2-tuple of PartialConfigs by...
.and_then(|proj| {
Ok((
.map(|proj| {
(
// 4-1. Passing in the project-specific PartialConfig
proj.project_path(project),
// 4-2. Getting and converting to PartialConfig, or returning any Err() if one appears.
get_table(cfg_table, "all").and_then(PartialConfig::try_from)?,
))
get_table(cfg_table, "all")
.and_then(PartialConfig::try_from)
.unwrap_or(PartialConfig::default()),
)
})
.map(|pair| pair.0.merge(pair.1))
})
@@ -161,6 +165,12 @@ impl PartialConfig {
impl TryFrom<&Table> for PartialConfig {
type Error = crate::config::Error;
/// Scans properties out of a `toml::Table` to get a PartialConfig.
///
/// `Error::NoSuchProperty` is quietly ignored (mapped to `None`) since it
/// isn't an error in this context.
///
/// All other errors are propagated and should be treated as real failures.
fn try_from(value: &Table) -> Result<Self> {
Ok(Self {
// can't get table name because that key is gone by this point.
@@ -285,7 +295,7 @@ mod tests {
.map(PathBuf::from);
let load_result = get_config("/no/such/project", search_paths)?;
let expected = PartialConfig {
project_path: None,
project_path: Some(String::from("/no/such/project")),
owner: None,
repo: None,
gitea_url: Some(String::from("http://localhost:3000")),
@@ -304,10 +314,39 @@ mod tests {
.map(PathBuf::from);
let load_result = get_config("/some/other/path", search_paths)?;
let expected = PartialConfig {
gitea_url: Some(String::from("fake-url")),
..PartialConfig::default()
project_path: Some(String::from("/some/other/path")),
gitea_url: Some(String::from("fake-url")),
..PartialConfig::default()
};
assert_eq!(load_result, expected);
Ok(())
}
// Ensure that trying to load files that don't exist simply get skipped over
// instead of causing a short-circuit exit or other bogus output.
#[test]
fn test_get_config_many_missing_files() -> Result<()> {
let search_paths = [
"./test_data/not_real_1.toml",
"./test_data/not_real_2.toml",
"./test_data/not_real_3.toml",
"./test_data/not_real_4.toml",
"./test_data/not_real_5.toml",
"./test_data/sample_config.toml",
"./test_data/not_real_6.toml",
]
.into_iter()
.map(PathBuf::from);
let load_result = get_config("/home/robert/projects/gt-tool", search_paths)?;
let expected = PartialConfig {
project_path: Some(String::from("/home/robert/projects/gt-tool")),
owner: Some(String::from("robert")),
repo: Some(String::from("gt-tool")),
gitea_url: Some(String::from("http://localhost:3000")),
token: Some(String::from("fake-token")),
};
assert_eq!(load_result, expected);
Ok(())
}
}

View File

@@ -20,9 +20,11 @@ pub(crate) async fn decode_client_error(response: reqwest::Response) -> Result<A
#[derive(Debug)]
pub enum Error {
Placeholder, // TODO: Enumerate error modes
Placeholder, // TODO: Enumerate error modes
MissingGiteaUrl, // the gitea URL wasn't specified on the CLI, env, or config file.
MissingRepoFRQN, // either the owner, repo, or both weren't specified in the loaded PartialConfig
MissingRepoOwner,
MissingRepoName,
WrappedConfigErr(config::Error),
WrappedReqwestErr(reqwest::Error),
MissingAuthToken,

View File

@@ -1,4 +1,4 @@
use std::path;
use std::path::{self, PathBuf};
use gt_tool::cli::Args;
use gt_tool::structs::release::{CreateReleaseOption, Release};
@@ -12,33 +12,37 @@ use reqwest::header::ACCEPT;
async fn main() -> Result<(), gt_tool::Error> {
let args = Args::parse();
// TODO: Heuristics to guess project path
// See issue #8: https://git.gelvin.dev/robert/gt-tool/issues/8
let pwd = std::env::current_dir()
.map_err(|_e| gt_tool::Error::WrappedConfigErr(
gt_tool::config::Error::CouldntReadFile
))?;
let project_path =
args.project
.map(PathBuf::from)
.unwrap_or(std::env::current_dir().map_err(|_e| {
gt_tool::Error::WrappedConfigErr(gt_tool::config::Error::CouldntReadFile)
})?);
let config = gt_tool::config::get_config(
pwd.to_str().expect("I assumed the path can be UTF-8, but that didn't work out..."),
gt_tool::config::default_paths()
project_path
.to_str()
.expect("I assumed the path can be UTF-8, but that didn't work out..."),
gt_tool::config::default_paths(),
)?;
println!("->> Loaded Config: {config:?}");
// arg parser also checks the environment. Prefer CLI/env, then config file.
let gitea_url = args.gitea_url.or(config.gitea_url).ok_or(gt_tool::Error::MissingGiteaUrl)?;
// Config files split the repo FQRN into "owner" and "repo" (confusing naming, sorry)
// These must be merged back together and passed along.
let conf_fqrn = config.owner
.ok_or(gt_tool::Error::MissingRepoFRQN)
.and_then(| mut own| {
let repo = config.repo.ok_or(gt_tool::Error::MissingRepoFRQN)?;
own.push_str("/");
own.push_str(&repo);
Ok(own)
});
let repo_fqrn = args.repo
.ok_or(gt_tool::Error::MissingRepoFRQN)
.or(conf_fqrn)?;
let gitea_url = args
.gitea_url
.or(config.gitea_url)
.ok_or(gt_tool::Error::MissingGiteaUrl)?;
let owner = args
.owner
.or(config.owner)
.ok_or(gt_tool::Error::MissingRepoOwner)?;
let repo = args
.repo
.or(config.repo)
.or_else(infer_repo)
.ok_or(gt_tool::Error::MissingRepoName)?;
let repo_fqrn = format!("{owner}/{repo}");
let mut headers = reqwest::header::HeaderMap::new();
headers.append(ACCEPT, header::HeaderValue::from_static("application/json"));
@@ -64,7 +68,7 @@ async fn main() -> Result<(), gt_tool::Error> {
releases.iter().rev().map(|release| release.colorized()),
String::from(""),
)
.map(|release| println!("{}", release))
.map(|release| println!("{release}"))
.fold((), |_, _| ());
}
gt_tool::cli::Commands::CreateRelease {
@@ -121,11 +125,7 @@ async fn main() -> Result<(), gt_tool::Error> {
}
for file in files {
let _attach_desc = gt_tool::api::release_attachment::create_release_attachment(
&client,
&gitea_url,
&repo_fqrn,
release.id,
file,
&client, &gitea_url, &repo_fqrn, release.id, file,
)
.await?;
}
@@ -172,3 +172,10 @@ fn match_release_by_tag(tag: &String, releases: Vec<Release>) -> Option<Release>
}
release
}
fn infer_repo() -> Option<String> {
let pwd = std::env::current_dir().ok()?;
let file_name = pwd.file_name()?;
let file_name_string = file_name.to_str()?;
Some(String::from(file_name_string))
}