diff --git a/content/blog/mirroring-gitea-to-other-repository-management-services.md b/content/blog/mirroring-gitea-to-other-repository-management-services.md
index 356cb73..3cb1263 100644
--- a/content/blog/mirroring-gitea-to-other-repository-management-services.md
+++ b/content/blog/mirroring-gitea-to-other-repository-management-services.md
@@ -9,17 +9,20 @@ title: Mirroring Gitea to Other Repository Management Services (GitHub, GitLab,
draft: false
---
+**NOTE**: Gitea now supports this out-of-the-box and probably fits your
+use-case: https://docs.gitea.io/en-us/repo-mirror/
+
I have a [Gitea][gitea] instance I self-host at home. I keep most of my
repositories there, but I recognize that most other developers and potential
-employers will want to see [my work *on* GitHub][me-on-github].
+employers will want to see [my work _on_ GitHub][me-on-github].
# TL;DR
-+ Setup an SSH key for your Gitea instance on the relevant external repositories
-+ Leverage `post-receive` git hooks in Gitea to push changes to the relevant
- external repositories while identifying with your new SSH key
+- Setup an SSH key for your Gitea instance on the relevant external repositories
+- Leverage `post-receive` git hooks in Gitea to push changes to the relevant
+ external repositories while identifying with your new SSH key
Also, most of the magic is [here](#post-receive-script).
@@ -43,16 +46,16 @@ Gitea supports a few [git hooks][1], which are a simple way to run a script when
something happens. As far as a repository manager is concerned, the only real
hooks that matter are the following (which Gitea supports):
-+ `pre-receive`: Runs when a client pushes code to the repository. You can use
- this to prevent, for example, code that fails linters, doesn't pass tests,
- or even that can't be merged using a specific merge strategy.
-+ `update`: Runs for each branch being updated when a client pushes code to the
- repository. This is similar to pre-receive, but allows for more fine-grained
- control. Maybe you want to only make the previous restrictions on your
- `master` branch. This would be the way to do it.
-+ `post-receive`: Runs after your `pre-receive` and `update` hooks have finished
- when a client pushes code to the repository. This is what we'll be
- leveraging to push code downstream!
+- `pre-receive`: Runs when a client pushes code to the repository. You can use
+ this to prevent, for example, code that fails linters, doesn't pass tests,
+ or even that can't be merged using a specific merge strategy.
+- `update`: Runs for each branch being updated when a client pushes code to the
+ repository. This is similar to pre-receive, but allows for more fine-grained
+ control. Maybe you want to only make the previous restrictions on your
+ `master` branch. This would be the way to do it.
+- `post-receive`: Runs after your `pre-receive` and `update` hooks have finished
+ when a client pushes code to the repository. This is what we'll be
+ leveraging to push code downstream!
With that lengthy introduction, let's dive in!
@@ -62,17 +65,17 @@ Alrighty, this has a few simple steps, so let's outline what we need to do
first:
1. Setup SSH keys for Gitea and your other repository management services
- 1. Generate fresh keys (`ssh-keygen -f gitea` will generate a private key in
- the `gitea` file and a public key in the `gitea.pub` file)
- 2. Add the public key (`gitea.pub`) to your "mirrors-to-be" repositories *with
- write access*
- + **Note**: I recommend at the very least to create one Gitea key and add it
- to the individual repositories, though individual keys for each repository
- is tighter security in case your Gitea instance becomes compromised
- + **Note**: Your "mirrors-to-be" repositories must be blank or have related
- histories!
+ 1. Generate fresh keys (`ssh-keygen -f gitea` will generate a private key in
+ the `gitea` file and a public key in the `gitea.pub` file)
+ 2. Add the public key (`gitea.pub`) to your "mirrors-to-be" repositories _with
+ write access_
+ - **Note**: I recommend at the very least to create one Gitea key and add it
+ to the individual repositories, though individual keys for each repository
+ is tighter security in case your Gitea instance becomes compromised
+ - **Note**: Your "mirrors-to-be" repositories must be blank or have related
+ histories!
2. Setup the `post-receive` hook on your Gitea repository to push using the
- newly generated private key to the mirror(s)
+ newly generated private key to the mirror(s)
I'm not going to explain much on how to add Deploy Keys for the various
repository management systems out there, so here's a link [explaining the process
@@ -84,9 +87,8 @@ Now we're all set for the magic! Also, for reference and sanity, I'm running
Gitea in Docker on an Arch Linux server with the following version (but this
should work pretty much regardless):
-+ Gitea Version: `3b612ce built with go1.11.5 : bindata, sqlite,
- sqlite_unlock_notify`
-+ Git Version: `2.18.1`
+- Gitea Version: `3b612ce built with go1.11.5 : bindata, sqlite, sqlite_unlock_notify`
+- Git Version: `2.18.1`
Let's go ahead and open up our Gitea repository's index page.
diff --git a/content/ourcraft-status.md b/content/ourcraft-status.md
new file mode 100644
index 0000000..928594c
--- /dev/null
+++ b/content/ourcraft-status.md
@@ -0,0 +1,96 @@
+---
+title: Ourcraft Server Status Checker
+---
+
+
+ Checking ourcraft.lyte.dev server status...
+
+
+
+
+ Failed to retrieve ourcraft.lyte.dev server status. Unfortunately, that usually means we're OFFLINE.
+
+
+ Please yell at @lytedev in the Ourcraft Discord to fix it!
+