fixed inaccuracies in articles steps

This commit is contained in:
Arunavo Ray
2025-10-23 00:04:58 +05:30
parent fa5f7da5c4
commit cb266b9af0
6 changed files with 15 additions and 15 deletions

View File

@@ -28,7 +28,7 @@ cd gitea-mirror
docker compose -f docker-compose.alt.yml up -d
```
The `alt` compose file ships with sane defaults for a single-node backup mirror. It stores data in `./data`. If you need a different location, set `DATA_DIR=/path` in `.env` before boot.
The `alt` compose file ships with sane defaults for a single-node backup mirror. It stores data in `./data`. To use a different path, edit the volume mapping (for example `- /srv/gitea-mirror:/app/data`).
Verify the containers:
@@ -53,9 +53,9 @@ Wait for "Server started" before moving on.
On the dashboard:
1. Click **Sync Now** for a small test repository.
1. Click **Mirror Repository** for a small test project.
2. Open Gitea and confirm the mirror appears with the right owner/org.
3. Enable **Mirror metadata** and **Mirror LFS** if you rely on issues, wikis, or large assets.
3. In **Configuration → Connections**, open the **Content & Data** section to enable **Mirror metadata** and **Git LFS** if you rely on issues, wikis, or large assets.
For broader coverage, switch the organization strategy to **Preserve structure** so Gitea mirrors your GitHub org layout automatically.
@@ -109,7 +109,7 @@ Treat the mirror like any other DR asset:
### Does Gitea Mirror copy issues, pull requests, releases, and LFS?
Yes. Enable Mirror metadata, Mirror releases, and LFS under Repository defaults. Pull requests are mirrored as enriched issues with linked branches and metadata.
Yes. Enable Mirror metadata, Mirror releases, and Git LFS from **Configuration → Connections → Content & Data**. Pull requests are mirrored as enriched issues with linked branches and metadata.
### How often should I sync GitHub backups?

View File

@@ -63,9 +63,9 @@ Shell scripts and `git clone --mirror` jobs work until they dont—usually wh
## Validate automation
- Force a failure by temporarily revoking a PAT; the next scheduler run should flag the repository in the Activity Log. Restore the token and trigger **Sync now** to confirm recovery.
- Force a failure by temporarily revoking a PAT; the next scheduler run should flag the repository in the Activity Log. Restore the token and use **Sync Repository** to confirm recovery.
- Run `bun run manage-db check` (or the UI health check) to ensure migrations and tasks are clean.
- Export the repositories table or CSV download to confirm `Last mirrored` timestamps match your configured interval.
- Spot-check the **Repositories** table or export the Activity Log CSV to confirm `Last mirrored` timestamps match your configured interval.
## Best practices

View File

@@ -22,7 +22,7 @@ GitHub accounts get banned, repos go private, and owners rage-delete history. If
### 1. Set archival-friendly defaults
In **Configuration → Connections**, open **Repository defaults**:
In **Configuration → Connections**, open **Content & Data**:
- Enable **Mirror metadata** and choose the components you care about (issues, pull requests, labels, milestones, wiki).
- Enable **Mirror releases** and raise the **Latest releases** limit if you need a deeper history of release assets.
@@ -50,7 +50,7 @@ In **Configuration → Connections**, open **Repository defaults**:
- In **Configuration → Automation**, enable **Automatic syncing** and set the interval (`1h` keeps fast-moving repos current; `12h` is usually enough for archives).
- Turn on **Handle orphaned repositories automatically** and leave the action on **Archive** so anything deleted upstream is preserved locally but marked read-only.
- Bump the **Latest releases** limit or run an occasional manual **Sync now** for milestone projects to capture older release assets.
- Bump the **Latest releases** limit or run an occasional manual sync from the **Repositories** table when you need older release assets.
### 4. Record provenance
@@ -86,7 +86,7 @@ In **Configuration → Connections**, open **Repository defaults**:
### Does this preserve issues, pull requests, and releases?
Yes—enable Mirror metadata and Mirror releases in Repository defaults. Pull requests copy as enriched issues, keeping discussion and labels.
Yes—enable Mirror metadata and Mirror releases from **Configuration → Connections → Content & Data**. Pull requests copy as enriched issues, keeping discussion and labels.
### What happens if a GitHub repo is deleted or goes private?

View File

@@ -43,7 +43,7 @@ Accept the defaults or adjust as needed. The script downloads the release, insta
1. Browse to `http://<container-ip>:4321`.
2. Create the admin account (first user = admin).
3. Enter your GitHub PAT and Gitea API token in the onboarding wizard.
4. Select the GitHub owners you want mirrored and enable auto-discovery for new repos.
4. Select the GitHub owners you want mirroredauto-discovery runs by default once scheduling is enabled, so new repositories appear automatically.
### 3. Validate persistence and services

View File

@@ -28,8 +28,8 @@ Stars are a personal library—but they vanish when creators delete repos or you
### 2. Categorize the collection
- Create sub-organizations in Gitea (e.g. `stars-iot`, `stars-ai`).
- Use the inline destination editor on the **Repositories** page to route specific stars into themed orgs.
- Create sub-organizations in Gitea (e.g. `stars-iot`, `stars-ai`) if you want separate spaces you can curate manually.
- Starred mirrors always land in the dedicated starred org, so use repository labels or Gitea teams to slice the collection by language, topic, or priority.
- Tag repos in Gitea with labels like `language:rust`, `topic:homelab` for quick filtering.
<figure class="mt-8 flex flex-col items-center">
@@ -59,7 +59,7 @@ Stars are a personal library—but they vanish when creators delete repos or you
## Verify the collection works
1. Star a new repo on GitHub.
2. Wait for the star interval or click **Sync now** in the dashboard.
2. Wait for the star interval or run **Sync Repository** from the dashboard for an immediate refresh.
3. Confirm the repo appears in your `stars` org with issues/releases intact.
4. Unstar it on GitHub; if cleanup is set to **Archive**, verify the mirror is renamed with an `archived-` prefix and marked read-only. If you chose **Delete**, confirm it disappears on the next sync.

View File

@@ -53,7 +53,7 @@ You may still collaborate on GitHub every day, yet want a LAN Gitea copy you con
### 4. Mirror metadata and LFS
Under **Repository defaults**:
In **Configuration → Connections → Content & Data**:
- Enable **Mirror metadata** so issues, pull requests (as enriched issues), labels, milestones, and wikis stay in sync.
- Enable **Mirror LFS** if your repos store binaries; confirm your Gitea instance has LFS enabled.
@@ -61,7 +61,7 @@ Under **Repository defaults**:
### 5. Validate the local mirror
- Select a repo in the dashboard and click **Sync now**.
- Select a repository in the dashboard and use the **Sync Repository** action.
- In Gitea, verify commit history, tags, issues, and releases match GitHub.
- Run a quick diff: `git remote add gitea http://<gitea>/<owner>/<repo>.git && git fetch gitea` then `git log origin/main..gitea/main` — it should be empty.