https://github.com/coderj001/go-wallhaven
It's wallpaper manager for wallhaven, written in golang.
https://github.com/coderj001/go-wallhaven
go golang goroutine wallpaper
Last synced: 9 months ago
JSON representation
It's wallpaper manager for wallhaven, written in golang.
- Host: GitHub
- URL: https://github.com/coderj001/go-wallhaven
- Owner: coderj001
- License: mit
- Created: 2023-01-15T15:42:11.000Z (over 3 years ago)
- Default Branch: master
- Last Pushed: 2024-06-15T14:44:21.000Z (almost 2 years ago)
- Last Synced: 2024-06-22T18:51:41.886Z (almost 2 years ago)
- Topics: go, golang, goroutine, wallpaper
- Language: Go
- Homepage:
- Size: 189 KB
- Stars: 5
- Watchers: 1
- Forks: 0
- Open Issues: 2
-
Metadata Files:
- Readme: README.md
- Contributing: CONTRIBUTING.md
- License: LICENSE
- Code of conduct: CODE_OF_CONDUCT.md
- Security: SECURITY.md
Awesome Lists containing this project
README
# go-wallhaven
[][github-actions]
[][github-actions-tests]
[](https://github.com/securego/gosec)
[][dependabot-pulls]
[][github-releases]
[][precommit-config]
[][project-license]
[][gomod-file]
## Installation (Binary)
Download binary from [releases](https://github.com/coderj001/go-wallhaven/releases) or build with `go build .`.
If you have api key, it free and will suggest to create a free account, create a file `.go-wallhaven` at home dir
```json
{
"API_KEY" : "",
"DIR" : ""
}
```
## Initial Setup
This section is intended to help developers and contributors get a working copy of
`go-wallhaven` on their end
1. Clone this repository
```sh
git clone https://github.com/coderj001/go-wallhaven
cd go-wallhaven
```
2. Install `golangci-lint`
Install `golangci-lint` from the [official website][golangci-install] for your OS
## Local Development
This section will guide you to setup a fully-functional local copy of `go-wallhaven`
on your end and teach you how to use it! Make sure you have installed
[golangci-lint][golangci-install] before following this section!
**Note:** This section relies on the usage of [Makefile][makefile-official]. If you
can't (or don't) use Makefile, you can follow along by running the internal commands
from [`go-wallhaven's` Makefile][makefile-file] (most of which are
OS-independent)!
### Installing dependencies
To install all dependencies associated with `go-wallhaven`, run the
command
```sh
make install
```
### Using Code Formatters
Code formatters format your code to match pre-decided conventions. To run automated code
formatters, use the Makefile command
```sh
make codestyle
```
### Using Code Linters
Linters are tools that analyze source code for possible errors. This includes typos,
code formatting, syntax errors, calls to deprecated functions, potential security
vulnerabilities, and more!
To run pre-configured linters, use the command
```sh
make lint
```
### Running Tests
Tests in `go-wallhaven` are classified as *fast* and *slow* - depending
on how quick they are to execute.
To selectively run tests from either test group, use the Makefile command
```sh
make fast-test
OR
make slow-test
```
Alternatively, to run the complete test-suite -- i.e. *fast* and *slow* tests at one
go, use the command
```sh
make test
```
### Running the Test-Suite
The *`test-suite`* is simply a wrapper to run linters, stylecheckers and **all** tests
at once!
To run the test-suite, use the command
```sh
make test-suite
```
In simpler terms, running the test-suite is a combination of running [linters](#using-code-linters)
and [all tests](#running-tests) one after the other!
## Additional Resources
### Makefile help
Tap for a list of Makefile commands
| Command | Description | Prerequisites |
|:--------------: |:-----------------------------------------------------------------------: |:-------------: |
| `help` | Generate help dialog listing all Makefile commands with description | NA |
| `install` | Fetch project dependencies | NA |
| `codestyle` | Run code-formatters | golangci-lint |
| `lint` | Check codestyle and run linters | golangci-lint |
| `test` | Run **all** tests | NA |
| `fast-tests` | Selectively run *fast* tests | NA |
| `slow-tests` | Selectively run *slow* tests | NA |
| `test-suite` | Check codestyle, run linters and **all** tests | golangci-lint |
| `run` | Run *go-wallhaven* | NA |
| `docker-gen` | Create production docker image for *go-wallhaven* | docker |
| `docker-debug` | Create debug-friendly docker image for *go-wallhaven* | docker |
| `clean-docker` | Remove docker image generated by `docker-gen` | docker |
Optionally, to see a list of all Makefile commands, and a short description of what they
do, you can simply run
```sh
make
```
Which is equivalent to;
```sh
make help
```
Both of which will list out all Makefile commands available, and a short description
of what they do!
### Generating Binaries
To generate binaries for multiple OS/architectures, simply run
```sh
bash build-script.sh
```
The command will generate binaries for Linux, Windows and Mac targetting multiple
architectures at once! The binaries, once generated will be stored in the `bin`
directory inside the project directory.
The binaries generated will be named in the format
```text
go-wallhaven___.
```
The `` is optional. By default, `version` is an empty string. A custom
version can be passed as an argument while running the script. As an example;
```sh
bash build-script.sh v1.2.1
```
An example of the files generated by the previous command will be;
```sh
go-wallhaven_v1.2.1_windows_x86_64.exe
```
### Setting up Codecov
Follow [Codecov Docs][codecov-docs] to activate Codecov for your project repository.
Once you've activated Codecov for your project, you should be able to see the
`Repository Upload Token`. Copy this token, and add it as a secret to your Github
repository. Checkout [Creating secrets for a Repository][creating-secrets] for info
on how to add secrets on Github.
For the secret, the name of the secret should be "`CODECOV_TOKEN`" (no spaces,
copy-paste the string as it is). The value of the secret would be the
`Repository Upload Token` obtained from Codecov.
Save the secret, you should be able to a secret named `CODECOV_TOKEN` in the
*Settings > Secrets* section of your project repository. If this field is visible,
you are done with setting up Codecov, and should be able to see code coverage reports
after the next run of CI pipeline!
### Using Docker
To run `go-wallhaven` in a docker container, read the instructions in
[docker section](./docker).
### Running `go-wallhaven`
To run go-wallhaven, use the command
```sh
make run
```
Additionally, you can pass any additional command-line arguments (if needed) as the
argument "`q`". For example;
```sh
make run q="--help"
OR
make run q="--version"
```
## Releases
You can check out a list of previous releases on the [Github Releases][github-releases]
page.
### Semantic versioning with Release Drafter
What is Semantic Versioning?
Semantic versioning is a versioning scheme aimed at making software management easier.
Following semantic versioning, version identifiers are divided into three parts;
```sh
..
```
> MAJOR version when you make incompatible API changes [breaking changes]
> MINOR version when you add functionality in a backwards compatible manner [more features]
> PATCH version when you make backwards compatible bug fixes [bug fixes and stuff]
For a more detailed description, head over to [semver.org][semver-link]
[Release Drafter][release-drafter] automatically updates the release version as pull
requests are merged.
Labels allowed;
- `major`: Affects the `` version number for semantic versioning
- `minor`, `patch`: Affects the `` version number for semantic versioning
Whenever a pull request with one of these labels is merged to the `master` branch,
the corresponding version number will be bumped by one digit!
### List of Labels
Pull requests once merged, will be classified into categories by
[release-drafter][release-drafter] based on pull request labels
This is managed by the [`release-drafter.yml`][release-drafter-config] config file.
| **Label** | **Title in Releases** |
|:-------------------------------------------------------: |:-------------------------------: |
| `security` | :lock: Security |
| `enhancement`, `feature`, `update` | :rocket: Updates |
| `bug`, `bugfix`, `fix` | :bug: Bug Fixes |
| `documentation`, `docs` | :memo: Documentation |
| `wip`, `in-progress`, `incomplete`, `partial`, `hotfix` | :construction: Work in Progress |
| `dependencies`, `dependency` | :package: Dependencies |
| `refactoring`, `refactor`, `tests`, `testing` | :test_tube: Tests and Refactor |
| `build`, `ci`, `pipeline` | :robot: CI/CD and Pipelines |
The labels `bug`, `enhancement`, and `documentation` are automatically created by Github
for repositories. [Dependabot][dependabot-link] will implicitly create the
`dependencies` label with the first pull request raised by it.
The remaining labels can be created as needed!
## TODO:
1. Limit the number of go worker should be user input
2. Page input should be a range of pages (need to rewrite apifech function & others)
3. Resolution shlould be fzf style multi-select (will try to apply on other fields)
:
: