wip: ci
All checks were successful
Release CI action / build-and-push-container (push) Successful in 1m0s

This commit is contained in:
Asger Gitz-Johansen 2024-12-02 13:18:55 +01:00
parent 0ae9d04c26
commit 174216f998
2 changed files with 10 additions and 7 deletions

View File

@ -16,8 +16,9 @@ jobs:
- name: login - name: login
uses: docker/login-action@v3 uses: docker/login-action@v3
with: with:
# NOTE: See https://gitea.com/gitea/docs/pulls/77/files
registry: git.gtz.dk registry: git.gtz.dk
username: ${{ gitea.actor }} username: ${{ gitea.actor }}
password: ${{ secrets.CI_TOKEN }} password: ${{ secrets.PACKAGE_TOKEN }}
- name: push container - name: push container
run: docker push git.gtz.dk/${{ gitea.repository }}:latest run: docker push git.gtz.dk/${{ gitea.repository }}:latest

View File

@ -123,16 +123,18 @@ I also have other projects that I host on my VPS (Virtual Private Server) such m
## Continuous Integration ## Continuous Integration
I am using my personal [gitea instance](https://git.gtz.dk/agj/blog) to host the source code for this blog - which means that I will be using the integrated CI system there, but you can use whichever CI service you'd like. I am using my personal [gitea instance](https://git.gtz.dk/agj/blog) to host the source code for this blog - which means that I will be using the integrated CI system there, but you can use whichever CI service you'd like.
The general concepts of the workflow should be fairly easy to translate to any kind of CI The general concepts of the workflow should be fairly easy to translate to any kind of CI, but this is how my setup looks like:
<!-- TODO: Implement the fucking thing -->
This setup also gives us the possibility of performing traditional code-review before releasing by using [pull requests]().
This should empower us to identify and correct issues (e.g. spelling mistakes or whatever) before they are pushed to the official website.
```yaml ```yaml
``` ```
Make sure to replace the `git.gtz.dk` website mentions with your own github hosting service (whether self-hosted, or `github.com`) and replace the `gitea/GITEA` mentions with `github/GITHUB` instead.
Note that the syntax is extemely similar to GitHub Actions - in fact Gitea Actions are trying to be 1 to 1 compatible with GitHub Actions, so it should be relatively straight forward.
This setup also gives us the possibility of performing traditional code-review before releasing by using [pull requests](https://docs.gitea.com/next/usage/pull-request?_highlight).
This should empower us to identify and correct issues (e.g. spelling mistakes or whatever) before they are pushed to the official website.
## Continuous Delivery ## Continuous Delivery
With a docker image readily available With a docker image readily available