Isang maliit na forge na maaari mong muling buuin.

Piliin ang layer ng kolaborasyon

Ang Forgejo at Gitea ay mga halimbawa ng magaan na forge software; maaaring sapat na ang plain SSH Git para sa mas maliit na workflow. Itugma ang issues, reviews, package storage at identity requirements sa proyekto. I-verify ang kasalukuyang sinusuportahang mga bersyon at lisensya.

Ihiwalay ang mga build mula sa forge

Ang CI runner ay nagpapatupad ng code na kontrolado ng proyekto at hindi dapat humawak ng walang limitasyong forge o host credential. Ihiwalay ang mga runner, limitahan ang saklaw ng token at iwasang patakbuhin ang mga hindi pinagkakatiwalaang job sa parehong privileged account ng repository service.

Protektahan ang pag-access at pagpaparehistro

I-disable ang pampublikong signup kapag pribado ang serbisyo. Gumamit ng indibidwal na account, malakas na authentication at maingat na scoped deployment key. Idokumento ang SSH port at host key; huwag tahimik na sanayin ang mga user na huwag pansinin ang mga babala sa host-key.

I-back up ang buong serbisyo

Ang mga repositoryo lamang ay maaaring hindi kasama ang mga isyu, account, attachment at configuration. Sundin ang pare-parehong pamamaraan ng backup ng forge at subukan ang pag-restore nang buo ang mga file permission at application secret.

Isang checklist sa pagbawi ng forge

I-export nang pare-pareho ang database at panatilihin ang repository storage, attachments, large-file storage kung naka-enable, configuration at encryption secrets. I-verify ang isang clone sa nilalayong SSH o HTTPS na ruta pagkatapos ng restoration. Panatilihing isolated ang forge at anumang CI worker para hindi maisulat muli ng isang build ang sariling configuration ng serbisyo.

Panatilihing makitid ang mga karapatan sa deployment

Ang isang read-only na deployment key ay maaaring sapat para sa isang server na kumukuha lamang ng code. Ang isang release automation ay maaaring mangailangan ng maliit na karagdagang scope. Mas mainam ang mga independiyenteng key para sa iba't ibang makina, itala ang kanilang layunin at alisin ang mga ito kapag retirado na ang makina.

Gamitin ang pinakamaliit na serbisyo ng kolaborasyon na angkop

Para sa ilang pribadong repository, maaaring sapat ang bare Git sa restricted na SSH. Ang Forgejo o Gitea ay nagdadagdag ng accounts, pull requests, issues at opsyonal na packages kapalit ng database, application updates at mas maraming persistent state. Itala kung aling feature ang aktwal na gagamitin ng team. I-budget nang hiwalay ang paglaki ng repository, large-file objects, attachments at build artefacts; maaaring lumampas ang CI compute sa forge mismo.

• Pumili ng canonical na HTTPS name at protektahan ang DNS account nito.
• Magpasya kung sarado, batay sa imbitasyon o moderated ang signup.
• Bigyan ang forge service ng unprivileged na identity at matibay na pribadong storage.

Opisyal na dokumentasyon: Pag-install ng Forgejo container

Ihiwalay ang web, SSH at database paths

Gamitin ang upstream configuration para sa napiling release at i-pin ang nilalayong image version. Dapat maabot ng isang TLS reverse proxy ang internal web listener; dapat maabot ang database ng forge lamang. Kung gumagamit ang Git SSH ng container port, panatilihing pare-pareho ang advertised host at external port nito sa mapping. Huwag palitan o aksidenteng ilantad ang host administrator SSH listener habang binabago ang forge. Isara ang installation/setup access kapag naisagawa na ang unang owner.

• Suriin ang pagmamay-ari ng persistent volume bago simulan ang application.
• Gumamit ng database user na limitado sa forge database.
• Panatilihin ang CI runners sa hiwalay na trust boundary, lalo na para sa mga hindi pinagkakatiwalaang repository.

Opisyal na dokumentasyon: Forgejo Docker networking at persistence

I-verify ang clone, push at isang denied na operasyon

Gumawa ng disposable na pribadong repository at subukan ang HTTPS o SSH clone URL nito mula sa isang normal na developer account. Mag-commit at mag-push ng isang hindi mapanganib na file, pagkatapos ay i-verify na makukuha ito ng isa pang awtorisadong reader. Dapat mabigo ang isang hindi inanyayahang account na basahin ang pribadong repository. Suriin ang paghawak ng malalaking file at notification email kung pinagana. Para sa mga deployment-only na machine, subukan na ang read-only key ay makakakuha at hindi makakapag-push; ang tagumpay sa authentication lamang ay hindi nagpapatunay ng inilaan na hangganan ng pahintulot.

# Use the disposable repository URL advertised by your forge:
git clone ssh://[email protected]:2222/team/check.git
# In a clone, inspect which remote is configured:
git remote -v

I-recover ang diskusyon pati na ang repository

Kumuha ng pare-parehong backup ng application/database, repository storage, attachment, LFS data, configuration at mga kinakailangang encryption secret. Sundin ang backup procedure ng naka-install na bersyon ng forge; ang mga backup command ng Gitea ay hindi awtomatikong mapapalitan sa bawat release ng Forgejo. I-rebuild nang isolated at i-verify ang isang issue, attachment, login at clone. Kung nabigo ang push pagkatapos ng paglipat, suriin ang SSH host/port, key mapping, storage permission at naka-advertise na clone URL bago baguhin ang mga permiso ng repository sa buong sistema.

Opisyal na dokumentasyon: Backup at restore ng Gitea