<div align="center">
<img alt="Gitea" src="https://user-images.githubusercontent.com/194400/168781665-a52d2c00-8b69-44ae-a10a-7bd1c3932020.svg" width="240"/>
**`Elixir`** interface with a **`Gitea`** instance.
[![GitHub Workflow Status](https://img.shields.io/github/workflow/status/dwyl/gitea/Elixir%20CI?label=build&style=flat-square)](https://github.com/dwyl/gitea/actions/workflows/ci.yml)
[![codecov.io](https://img.shields.io/codecov/c/github/dwyl/gitea/main.svg?style=flat-square)](http://codecov.io/github/dwyl/gitea?branch=main)
[![Hex.pm](https://img.shields.io/hexpm/v/gitea?color=brightgreen&style=flat-square)](https://hex.pm/packages/gitea)
[![Libraries.io dependency status](https://img.shields.io/librariesio/release/hex/gitea?logoColor=brightgreen&style=flat-square)](https://libraries.io/hex/gitea)
[![docs](https://img.shields.io/badge/docs-maintained-brightgreen?style=flat-square)](https://hexdocs.pm/gitea/api-reference.html)
[![contributions welcome](https://img.shields.io/badge/contributions-welcome-brightgreen.svg?style=flat-square)](https://github.com/dwyl/gitea/issues)
[![HitCount](http://hits.dwyl.com/dwyl/gitea.svg)](http://hits.dwyl.com/dwyl/gitea)
<!-- uncomment when service is working ...
[![Inline docs](http://inch-ci.org/github/dwyl/auth.svg?branch=master&style=flat-square)](http://inch-ci.org/github/dwyl/auth)
-->
</div>
# _Why?_ 💡
We needed an _easy_ way to interact
with a **`Gitea`** (GitHub Backup) **Server**
from our **`Elixir/Phoenix`** App.
> **Note**: We were _briefly_ tempted
> to write this code _inside_ the Phoenix App
> that uses it, <br />
> however we quickly realized
> that having it **_separate_** was better
> for **_testability/maintainability_**. <br />
> Having a _separate_ module enforces a
> [separation of concerns](https://en.wikipedia.org/wiki/Separation_of_concerns)
> with a strong "API contract". <br />
> This way we know this package is well-tested both end-to-end and with
> [Test Doubles](https://martinfowler.com/bliki/TestDouble.html),
> documented and maintained. <br />
> It can be used and _extended independently_
> of any `Elixir/Phoenix` app
> and is treated
> as a logically separate/independent entity
> with a clear interface.
# _What_? 📦
A library for interacting with **`gitea`** (`git`)
from `Elixir` apps. <br />
Hopefully this diagram explains
how we use the package in our stack:
<div align="center">
![Phoenix-Gitea-Infra-dagram](https://user-images.githubusercontent.com/194400/168793143-3cf67409-6330-425e-a0b9-fff4c64e3e7f.png)
</div>
For the complete list of functions,
please see the docs:
[hexdocs.pm/**gitea**](https://hexdocs.pm/gitea)
📚
# Who? 👤
This library is used by our (`Phoenix`) GitHub Backup App. <br />
If you find it helpful for your project,
please ⭐ on GitHub:
[github.com/dwyl/**gitea**](https://github.com/dwyl/gitea)
## _How_? 💻
There are a couple of steps to get this working in your project.
It should only take **`2 mins`** if you already have your
**`Gitea` Server** _deployed_ (_or access to an existing instance_).
> If you want to read a **step-by-step complete beginner's guide**
> to getting **`gitea`** working in a **`Phoenix`** App,
> please see:
> [github.com/dwyl/**gitea-demo**](https://github.com/dwyl/gitea-demo)
<br />
## Install ⬇️
Install the package from [hex.pm](https://hex.pm/docs/publish),
by adding `gitea` to the list of dependencies in your `mix.exs` file:
```elixir
def deps do
[
{:gitea, "~> 1.1.0"},
]
end
```
Once you've saved the `mix.exs` file,
run:
```sh
mix deps.get
```
<br />
## Config ⚙️
If you are writing tests for a function that relies on `gitea` (and you should!)
then you can add the following line to your `config/test.exs` file:
```sh
config :gitea, mock: true
```
<br />
## _Setup_ 🔧
For `gitea` to work
in your `Elixir/Phoenix` App,
you will need to have
a few environment variables defined.
There are **2 _required_**
and **1 _optional_** variables.
Make sure you read through the next section
to determine if you _need_ the _optional_ ones.
### _Required_ Environment Variables
> See: [`.env_sample`](https://github.com/dwyl/gitea/blob/main/.env_sample)
There are **2 _required_** environment variables:
1. `GITEA_URL` - the domain where your Gitea Server is deployed,
without the protocol, e.g: `gitea-server.fly.dev`
2. `GITEA_ACCESS_TOKEN` - the REST API Access Token <br />
See: https://github.com/dwyl/gitea-server#7-create-access-token-api-key
### _Optional_ Environment Variables
#### `GIT_TEMP_DIR_PATH`
If you want to specify a directory where
you want to clone `git` repos to, <br />
create a `GIT_TEMP_DIR_PATH` environment variable.
e.g:
```sh
export GIT_TEMP_DIR_PATH=tmp
```
> **Note**: the directory **must _already_ exist**.<br />
> If it doesn't already exist, create it. <br />
> e.g:
> `mkdir tmp` followed by `cp -r test-repo tmp`
<br />
## Usage
If you just want to _read_
the contents of a file hosted on
a `Gitea` Server,
write code similar to this:
```elixir
org_name = "myorg"
repo_name = "public-repo"
file_name = "README.md"
{:ok, %HTTPoison.Response{ body: response_body}} =
Gitea.remote_read_raw(org_name, repo_name,file_name)
# use the response_body (plaintext data)
```
This is exactly the use-case presented in our demo app:
[dwyl/**gitea-demo**#4-create-function](https://github.com/dwyl/gitea-demo#4-create-function-to-interact-with-gitea-repo)
<br />
Here's a more real-world scenario
in 7 easy steps:
### 1. _Create_ a New Repo on the Gitea Server
```elixir
# Define the params for the remote repository:
org_name = "myorg"
repo_name = "repo-name"
private = false # boolean
# Create the repo!
Gitea.remote_repo_create(org_name, repo_name, private)
```
### 2. _Clone_ the Repo
```elixir
git_repo_url = Gitea.Helpers.remote_url_ssh(org_name, repo_name)
Gitea.clone(git_repo_url)
```
> Provided you have setup the environment variables,
> and your `Elixir/Phoenix` App has write access to the filesystem,
> this should work without any issues.
> We haven't seen any in practice.
> But if you get stuck at this step,
> [open an issue](https://github.com/dwyl/gitea/issues)
### 3. _Read_ the Contents of _Local_ (Cloned) File
Once you've cloned the `Git` Repo from the `Gitea` Server
to the local filesystem of the `Elixir/Phoenix` App,
you can read any file inside it.
```elixir
org_name = "myorg"
repo_name = "public-repo"
file_name = "README.md"
{:ok, text} = Gitea.local_file_read(org_name, repo_name, file_name)
```
### 4. _Write_ to a File
```elixir
file_name = "README.md"
text = "Your README.md text"
Gitea.local_file_write_text(org_name, repo_name, file_name, text)
```
This will create a new file if it doesn't already exist.
### 5. _Commit_ Changes
```elixir
{:ok, msg} = Gitea.commit(org_name, repo_name,
%{message: "your commit message", full_name: "Al Ex", email: "alex@dwyl.co"})
```
### 6. _Push_ to `Gitea` Remote
```elixir
# Push to Gitea Server this one is easy.
Gitea.push(org_name, repo_name)
```
### 7. _Confirm_ the File was Update on the Remote repo
```elixir
# Confirm the README.md was updated on the remote repo:
{:ok, %HTTPoison.Response{ body: response_body}} =
Gitea.remote_read_raw(org_name, repo_name, file_name)
"Your README.md text"
```
<br />
## Full Function Reference / Docs? 📖
Rather than duplicate all the docs here,
please read the complete function reference,
on hexdocs: https://hexdocs.pm/gitea/Gitea.html
<br />
## Tests!
By default, the tests run with "mocks",
this means that: <br />
1. Functional tests run faster (0.2 seconds)
2. Tests that require filesystem access will run on GitHub CI.
3. We know that functions are appropriately
["Test Doubled"]
so that a downstream `Elixir/Phoenix` app
can run in `mock: true` and tests will be mocked (and thus _fast_!)
To alter this setting to run the tests _without_ mocks,
simply change the boolean from:
```elixir
config :gitea, mock: true
```
To:
```elixir
config :gitea, mock: false
```
You should still see the same output as all the functions should be tested.
### Test Coverage
When you run the command:
```sh
mix c
```
(an alias for `mix coveralls.html`) <br />
You will see output similar to the following:
```sh
Finished in 0.1 seconds (0.1s async, 0.00s sync)
3 doctests, 27 tests, 0 failures
Randomized with seed 715101
----------------
COV FILE LINES RELEVANT MISSED
100.0% lib/git_mock.ex 55 7 0
100.0% lib/gitea.ex 212 41 0
100.0% lib/helpers.ex 131 17 0
100.0% lib/http.ex 119 18 0
100.0% lib/httpoison_mock.ex 124 20 0
[TOTAL] 100.0%
----------------
```
If you want to run the tests _without_ mocks (i.e. "end-to-end"),
update the line in `config/test.exs`:
```sh
config :gitea, mock: false
```
When you run end-to-end tests with coverage tracking:
```sh
mix c
```
You should see the same output:
```sh
Finished in 5.5 seconds (5.5s async, 0.00s sync)
3 doctests, 27 tests, 0 failures
Randomized with seed 388372
----------------
COV FILE LINES RELEVANT MISSED
100.0% lib/git_mock.ex 55 7 0
100.0% lib/gitea.ex 212 41 0
100.0% lib/helpers.ex 131 17 0
100.0% lib/http.ex 119 18 0
100.0% lib/httpoison_mock.ex 124 20 0
[TOTAL] 100.0%
----------------
```
The only difference is the **_time_** it takes to run the test suite. <br />
The outcome (all tests passing and **100% coverage**) should be **_identical_**.
If you add a feature to the package,
please ensure that the tests pass
in both `mock: true` and `mock: false`
so that we know it works in the _real_ world
as well as in the simulated one.
<br />
## Roadmap
We are aiming to do a 1:1 feature map between GitHub and `Gitea`
so that we can backup our entire organisation, all repos, issues, labels & PRs.
We aren't there yet
and we might not be for some time.
The order in which we will be working
on fleshing out the features is:
1. **Git Diff** - using the `Git` module to determine the changes made to a specific file
between two Git commits/hashes. This will allow us to visualize the changes made
and can therefore _derive_ the contents of a Pull Request
without having the PR feature exposed via the Gitea API.
See: https://github.com/dwyl/gogs/issues/27
2. **Issues**: https://github.com/gogs/docs-api/tree/master/Issues
- **Comments** - this is the core content of issues.
We need to parse all the data and map it to the fields in `Gitea`.
- **Labels** - the primary metadata we use to categorize our issues,
see: https://github.com/dwyl/labels
- **Milestones** - used to _group_ issues into batches, e.g. a "sprint" or "feature".
3. **Repo Stats**: Stars, watchers, forks etc.
4. **_Your_ Feature Request** Here!
Seriously, if you spot a gap in the list of available functions,
something you want/need to use `Gitea` in any a more advanced/custom way,
please open an issue so we can discuss!
<br />
## I'm _Stuck!_ 🤷
As always, if anything is unclear
or you are stuck getting this working,
please open an issue!
[github.com/dwyl/gitea/issues](https://github.com/dwyl/gitea/issues)
we're here to help!
<br />
<br />
<hr />
# ⚠️ Disclaimer! ⚠️
This package is provided "**as is**".
We make **_no guarantee/warranty_** that it _works_. <br />
We _cannot_ be held responsible
for any undesirable effects of it's usage.
e.g: if you use the [`Gitea.delete/1`](https://hexdocs.pm/gitea/Gitea.html#delete/1)
it will _permanently/irrecoverably_ **`delete`** the repo.
Use it with caution!
With the disclaimer out of the way,
and your expectations clearly set,
here are the facts:
We are using this package in "production".
We rely on it daily and consider it
["mission critical"](https://en.wikipedia.org/wiki/Mission_critical).
It works for _us_ an and
we have made every effort to document,
test & _maintain_ it.
If you want to use it, go for it!
But please note that we cannot "_support_" your usage
beyond answering questions on GitHub.
And unless you have a commercial agreement with
[dwyl Ltd.]
If you spot anything that can be improved,
please open an
[issue](https://github.com/dwyl/gitea/issues),
we're very happy to discuss!
[![feedback welcome](https://img.shields.io/badge/feedback-welcome-brightgreen.svg?style=flat-square)](https://github.com/dwyl/gitea/issues)