Bir script nasıl güncellenir

Güncel olmayanları bulCopy Anchor Link

Konsol uyarısı sadece çalışan ve yok sayılmayan scriptleri kapsar, o yüzden her klasörü kontrol et:

cd "resources/[ai]"
for n in ai-*; do
  repo=$(sed -n 's#.*"repository": *"\(github:\|https://github.com/\)\([^"]*\)".*#\2#p' "$n/package.json" | sed 's#\.git$##')
  cur=$(sed -n 's#^  "version": *"\([^"]*\)".*#\1#p' "$n/package.json")
  latest=$(gh release view --repo "$repo" --json tagName --jq .tagName 2>/dev/null | sed 's#^v##')
  echo "$n $cur ${latest:-no-release}"
done

• Sürümleri ai-core gibi karşılaştır: baştaki v harfini at, noktalı sayıları karşılaştır, pre-release eklerini yok say. Release yoksa güncellenecek bir şey de yok.
• gh yoksa: curl -s -H "Accept: application/vnd.github+json" https://api.github.com/repos/<owner>/<name>/releases/latest (IP başına saatte 60 istek, ai-core’un kendi kontrolüyle ortak).
• updates.ignore içindeki bir script sadece sunucu sahibi adını verirse güncellenir.
• Sürümü son release’in üstünde olan bir klasör ya da son tag’den sonra commit’i olan bir clone güncel olmayan sayılmaz: atla, bir klasörü asla geriye taşıma.
• packages/ klasöründe repository satırı yok: her package.json sürümünü npm ile karşılaştır. Yeni bir script sürümü yerel kopyalarda olmayan bir sürüm istiyorsa önce paketleri güncelle.

Sürüm notlarını oku ve onay alCopy Anchor Link

Mevcut sürümle en son sürüm arasındaki her sürümün notlarını oku (gh release view <tag> --repo <repo> --json body,assets,url): uyumu bozan değişiklikler, istenen paket sürümleri, migration’lar, yeni cfg satırları (ensure, add_convar_permission, ACE), yeni provide adları, elle yapılacak adımlar.

Sunucu sahibine listeyi göster ve onayını bekle. Bağımlılık sırasıyla güncelle: paketler, ai-mysql, ai-core, ai-lib, sonra diğerleri.

Eski ve yeni upstream’i indirCopy Anchor Link

Her script için sunucunun dışında iki yeni boş klasör (örneğin update/<name>/old ve update/<name>/new):

gh release download <tag> --repo <owner>/<name> --archive zip --dir update/<name>/new     # tag'in kaynağı
gh release download <tag> --repo <owner>/<name> --pattern '*.zip' --dir update/<name>/new # varsa bir release dosyası
unzip -q update/<name>/new/*.zip -d update/<name>/new/x

• Release’e eklenmiş bir dosya varsa onu tercih et; yoksa tag’in kaynağını al (commit edilmiş dist/ ve fxmanifest.lua içindedir). Kaynak zip’inin en üst klasörü <owner>-<name>-<sha>/ olur.
• Eski upstream, sunucunun çalıştırdığı sürümün tag’idir (tag adlandırmasını gh release list --repo <owner>/<name> ile gör). Her zaman indirilebilir, yani üç yönlü karşılaştırmanın tabanı her zaman vardır.
• Bu klasörlerdeki hiçbir şey çalıştırılmaz, kurulmaz, build edilmez.

Yedek alCopy Anchor Link

• Script klasörünün tamamını node_modules hariç update/<name>/ours içine kopyala (Windows’ta robocopy "<src>" "<dst>" /E /XD node_modules; robocopy’nin 8’den küçük çıkış kodları başarı demek). Bu, birleştirme için "bizimki" ve geri dönüş yolun.
• Git’in yok saydığı dosyalar sadece bu kopyada var: data/secrets.json, data/*.json.bak. Bir git clone’unda git ls-files --others --ignored --exclude-standard onları listeler.
• Bir clone’daki commit edilmemiş değişiklikler (git status --porcelain) de sunucunun değişiklikleridir. Sunucu sahibine söyle; sadece isterse commit et.

Dosya dosya birleştirCopy Anchor Link

Üç yönlü modeli eski, bizimki ve yeni üzerinde çalıştır ve sonucu script klasörüne yaz:

Panel içeriği (data/*.json) sunucunun panelde düzenlenen canlı içeriğidir; release sadece varsayılanları getirir.

• Aynı şema (yeni schema.ts ya da loader aynı alanları okuyor): bizimkini olduğu gibi koru. Yeni sürümün eklediği bir dosya: geleni al.
• Değişen şema: scriptin açılışta çalışan kendi migration’ını ara (sürüm notları, açılışta çağrılan bir migration). Varsa bizimkini yerinde bırak; açılışta çevrilir. Yoksa yeni loader’ı ve şemayı izleyerek elle çevir: gelen dosyayla aynı alan adları, tipler ve id biçimi, her değer korunur, yeni alanlar gelen varsayılanla, kaldırılan alanlar çıkarılıp raporlanır. Her dosyanın parse edildiğini kontrol et.

Veritabanı. Her script tablolarını açılışta sql/main.sql dosyasından kurar: eksik tabloları oluşturur, eksik sütunları ekler; asla bir sütunu silmez, yeniden adlandırmaz, değiştirmez ya da key eklemez. Eski ve yeni sql/main.sql dosyalarını karşılaştır:

• Yeni tablolar ve sütunlar: yeniden başlatma onları uygular.
• Değişen bir sütun tipi, yeni bir index ya da key, yeniden adlandırılan ya da silinen bir sütun: release kendi migration’ını getirmeli (sürüm notları, server kodu), o da açılışta çalışır; logu kontrol et. Getirmiyorsa SQL’i yaz, sunucu sahibine göster, etkilenen tabloları yedekle ve sadece onun onayıyla çalıştır.

Klasör dışındaki cfg dosyaları.

• server.cfg: yeni bir script bağımlılık sırasına göre ensure satırını alır; kaldırılan bir script satırını kaybeder (önce sor).
• env.cfg ve env.example.cfg: veritabanı kullanmaya başlayan bir script add_convar_permission <resource> read mysql_connection_string ister.
• permission.cfg: sürüm notlarının istediği ACE satırları.
• security.cfg: asla gevşetilmez.

Build al, yeniden başlat, kontrol etCopy Anchor Link

1. Bir package.json değiştiyse sunucu kökünde bun install.

2. Güncellenen her scriptte: bun run typecheck, bun run lint, bun run build (ya da sunucu kökünden bun tools/run.ts build ai-x ai-y). Her zaman build al: dist/ birleştirilmiş kaynaktan gelmeli. Sunucunun taşınan değişikliklerindeki hataları düzelt; dokunulmamış upstream kodundaki bir hata düzeltilmez, raporlanır.

3. Sonucu yeni upstream ile karşılaştır: diff -r --strip-trailing-cr -x node_modules -x dist -x data update/<name>/new/x/<top> "<script folder>". Kalan her fark sunucunun değişikliklerinden biri olmalı.

4. Refresh et ve yeniden başlat:

   Metni kopyala

   bun tools/rcon.ts --log ../default/logs/fxserver.log --wait 3 "refresh"
   bun tools/restart.ts --from ai-inventory   # tek bir script
   bun tools/restart.ts                       # ai-core, ai-lib, ai-mysql ya da paket güncellemesinden sonra

   bun tools/restart.ts ai-core’u yeniden başlatır, ondan sonraki her ai-* için ensure çalıştırır ve her birinin başladığını kontrol eder. ai-mysql’e bağlı üçüncü parti scriptler onunla birlikte durur: onları adıyla yeniden ensure et. Yeni bir provide satırı sunucunun baştan açılmasını ister: bun tools/rcon.ts "quit \"<reason>\"".

5. Konsol logunda sadece Started resource satırına değil, SCRIPT ERROR, Failed to load script, [client error], panel yükleme ya da doğrulama hatalarına ve veritabanı hatalarına bak. is outdated uyarısı scriptin bir sonraki kontrolünden sonra kaybolmalı.

Geleni kurulu olanla eşleştirCopy Anchor Link

• fxmanifest.lua (ya da __resource.lua) içeren her üst düzey klasör bir resource’tur; bir [category] klasörü birkaç tane içerir. Zip’leri yeni ve boş bir klasöre aç, oradan hiçbir şey çalıştırma.
• Kurulu kopyayı resources/ içinde klasör adıyla bul (örneğin find resources -maxdepth 3 -type d -name <name>). Kurulu konumu koru, gelen klasörün kategorisini değil. Eşleşme yoksa ya da birden fazlaysa sunucu sahibine sor. Henüz kurulu olmayan bir script sadece sunucu sahibi söylerse kurulur.
• Gelenlerin içindeki bir ai-* klasörü bu akışa ait değil: ai-* scriptleri GitHub’dan güncellenir (yukarıda). Sunucu sahibine bu klasörün ne olduğunu sor.
• İki manifesti de oku: version, files, scriptler, dependencies, provide, escrow_ignore, ai_replaces. Sürümü düşen ya da kurulu kopyada olan dosyaları içermeyen bir paket eski bir build olabilir: kurmak yerine karşılaştır ve raporla.
• Yeni bağımlılıklar: oxmysql’i ai-mysql karşılar (asla yanına oxmysql kurma); ox_lib ve diğer kütüphaneleri sunucu sahibi kurar; ai-core’un yerini tuttuğu bir şeye bağımlılık (es_extended, qb-core, qbx_core, pma-voice, ox_inventory...) zaten karşılanmıştır.
• Eşleşen listeyi göster (ad, yol, mevcut -> yeni sürüm) ve onayı bekle.

Yedek alCopy Anchor Link

• Kurulu klasörün tamamını sunucunun dışındaki bir yedek klasörüne kopyala (robocopy "<src>" "<dst>" /E). Hiçbir git deposunun izlemediği bir klasörde bu yedek, sunucunun sürümünün tek kopyasıdır.
• Klasörü git izliyorsa: git status --porcelain -- <path> commit edilmemiş değişiklikleri gösterir (bizimki sayılır; sunucu sahibine söyle), git ls-files --others --ignored --exclude-standard -- <path> git’in yok saydığı çalışma dosyalarını gösterir (kaydedilmiş JSON, cache), bunlar yedektedir.

Sunucunun değişikliklerini bulCopy Anchor Link

Eski upstream’i şu sırayla al:

1. Sunucu sahibinde eski satıcı zip’i ya da klasörü hâlâ var.
2. GitHub’da açık kaynak bir script: kurulu sürümün release’i ya da tag’i.
3. Klasör izleniyorsa git geçmişi: kurulu version değerini koyan commit (git log -S"version '<old>'" -- <path>/fxmanifest.lua). O commit önceki özelleştirmeleri de yeniden uyguladıysa config dosyaları bizimki sayılır ve saf stok bir commit öncesidir.
4. Hiçbiri: bizimkini doğrudan yeni sürümle karşılaştır ve bunu raporda söyle.

Sonra eski -> bizimki farklarının hepsini (sunucunun düzenlemeleri: config’ler, locales/* ya da languages/*, editable dosyalar, data/*.json, fxmanifest.lua, SQL, resimler, sesler, stream dosyaları, kod yamaları) ve eski -> yeni farklarını (satıcının değişiklikleri: eklenen ve silinen dosyalar, yeniden adlandırılan anahtarlar, taşınan bölümler, değişen editable fonksiyonlar) oku. Escrow’lu bir scriptte (.fxap var) sadece escrow_ignore içindeki dosyalar okunup düzenlenebilir; yeni sürümün escrow’ladığı bir dosyadaki düzenleme taşınamaz ve raporlanır.

Yeni sürümü kurCopy Anchor Link

Kurulu klasörü tamamen sil, sonra yeni klasörü aynı yola kopyala, gizli dosyalar (.fxap) dahil. Eski artıklar hatadır; eski sürüm yedekte kalır. Yedeklenen çalışma dosyalarını sadece yeni sürüm onları aynı biçimde kullanıyorsa geri koy; yoksa çevir ya da çıkar ve raporla.

Sunucunun değişikliklerini yeniden uygulaCopy Anchor Link

Her düzenleme için o ayarın yeni sürümde nerede durduğunu bul ve değeri oraya yeni biçimde yaz:

• Aynı anahtar, aynı dosya: değeri yeni dosyada ayarla; yorumlarını ve düzenini koru.
• Yeniden adlandırılan ya da taşınan anahtar: onu kullanan kodu okuyarak yeni anahtarı bul (eski adı, yorumunu, varsayılanını, metin anahtarını ara) ve değeri yeni biçime çevir.
• Bir veri dosyasına taşınan config (scriptin kendi panelinin düzenlediği JSON): yeni loader’ı ve gelen dosyayı oku, eski değerleri tam o şemayla yaz (alan adları, tipler, id biçimi, girinti), parse edildiğini kontrol et. Scriptin çalıştırabileceği bir dönüştürücüye güvenme.
• Sunucunun mevcut veri dosyaları: taşı, şema değiştiyse alan alan çevir, asla satıcının örneğiyle değiştirme.
• Kaldırılan ayar: onu artık hiçbir kod okumuyor (bir arama doğrular): çıkar ve eski değeriyle raporla.
• Editable dosyalar (client/editable.lua, server/editable.lua...): yeni dosyadan başla ve değişen her fonksiyon gövdesini yeniden uygula, değişen imzaya ya da dönüş değerine uyarlayarak; yeni fonksiyonlar varsayılanda kalır.
• Diller: hâlâ var olan her anahtarda sunucunun ifadesini koru; yeni anahtarları sunucunun kullandığı her dil dosyasına mevcut metinlerin tonunda çevirerek ekle; kaldırılan anahtarları çıkar; değişen placeholder’ları izle.
• fxmanifest: yenisi, artı sadece hâlâ anlamlı olan sunucu eklemeleri. version asla değiştirilmez.
• SQL (*.sql, kurulum klasörleri): eskiyle yeniyi karşılaştır; yeni tablolar, sütunlar ve index’ler sunucu sahibinin çalıştıracağı SQL olarak rapora girer. Sunucu sahibinin onayı olmadan hiçbir şey çalışmaz.
• Kimlik bilgileri (config’lerdeki bot token’ları, API anahtarları, webhook adresleri): asla yazdırma. Yedekten taşı; mümkün değilse yeni varsayılanı bırak ve dosyayı ve anahtarı sunucu sahibi için listele.
• Asset’ler (stream/, resimler, sesler): satıcınınkiler, artı sunucunun eklediği ve hâlâ kullanılan dosyalar.
• Koordinatlar, item’lar, fiyatlar, metinler ve davranış birebir taşınır; sunucunun kendi düzenlemeleri dışında hiçbir şey değişmez.

ai-core uyumunu kontrol etCopy Anchor Link

Script, ai-core’un konuştuğu scriptlerden biri olabilir. Onun adının geçtiği her yeri bul:

grep -rln "<name>" "resources/[ai]/ai-core/resource" "resources/[ai]/ai-core/bridge" docs/compat

• Bir adapter’ın kullandığı her export, event ve callback için yeni sürümü kontrol et: hâlâ var mı, argümanlar aynı mı, dönüş biçimi aynı mı, zamanlama aynı mı. Escrow’lu kodda okunabilen dosyaları ve satıcının dokümanlarını kontrol et, doğrulanamayanları listele.
• Bir uyumsuzluk sadece adapter dosyasında düzeltilir (ince bir çeviri), test edilen sürümü yükseltilir; sonra ai-core için typecheck, lint ve build al ve onu yeniden başlat (bun tools/restart.ts).
• Yeni bir ai_replaces ya da provide satırı, bir ai-* yedeği hâlâ çalışırken ai-core’un girişleri reddetmesine yol açabilir (bkz. Bir ai-* script’ini değiştirmek): sunucu sahibinin silmesi gereken klasörün adını ver.
• docs/compat/<script>.md dosyasını güncelle (test edilen sürüm, durum, tam config ya da yama, bilinen sınırlar); notu olmayan desteklenen bir script bir not alır.

Doğrula ve yeniden başlatCopy Anchor Link

• Kurulu sonucu yeni sürümle karşılaştır: her fark sunucunun değişikliklerinden biri ve yeni sürümün getirmediği hiçbir eski dosya kalmamış (geri konan çalışma dosyaları hariç).
• Düzenlenen Lua parse ediliyor, JSON parse ediliyor, ayarlanan her config anahtarı yeni kodda var.
• Sunucu sahibini bekleyen SQL yoksa: bun tools/rcon.ts --log ../default/logs/fxserver.log --wait 3 "refresh", sonra aynısı "ensure <name>" ile, ve logda SCRIPT ERROR, Failed to load script ve scriptin kendi hatalarına bak. Ona bağlı olup duran scriptler yeniden ensure edilir.