Mohu to spustit na soukromém repozitáři zdarma?

Obvykle ano, v rámci měsíčních minut, které GitHub dává bezplatným účtům. Job snímku běží výrazně pod minutu, takže týdenní plánování používá malou část. Zkontrolujte aktuální povolení svého plánu, protože GitHub ho občas mění.

Kde by měl být klíč, pokud tlačí několik lidí?

V tajné proměnné organizace nebo repozitáře, nikdy v souborech. Kdokoli, kdo může upravovat workflow, může vytisknout tajnou proměnnou v logu, takže omezte, kdo má přístup pro zápis, a změňte klíč, pokud někdo opustí projekt.

Proč se můj plánovaný běh nespustil?

Tři obvyklé důvody. Soubor workflow není na výchozím vetvi, repozitář byl nečinný 60 dní a GitHub pozastavil plánování, nebo cron string má překlep. Spusťte jej jednou s workflow_dispatch, abyste vyloučili samotný skript.

Jak velké se složky dat stanou?

Malé. Tisíc odkazujících domén je několik set kilobajtů JSON. Rok týdenních souborů pro jednu doménu zůstává výrazně pod sto megabajty, což je pro git v pořádku, i když můžete starší složky komprimovat, pokud vám to vadí.

Runbook

Týdenní snímky zpětných odkazů v GitHub Actions: runbook

Cíl: každé pondělí workflow zapíše dnešní odkazující domény a kotvící texty do repozitáře. Nic víc. Porovnávání (diffing) přijde později.

Redakce Linkzoid · Aktualizováno 2026-10-28

Železný most přes řeku, symbolizující spolehlivou infrastrukturu plánovaných workflow

Než začnete

Potřebujete repozitář, klíč Linkzoid uložený jako tajnou proměnnou LZ_KEY a jednu doménu, kterou vlastníte. Rozpočet: cca 6 kreditů na cíl za běh, což je $0.0006. Snímek je fakt o jednom měsíci, takže týdenní běhy většinou znovu načtou stejný index. Nastavení kontroly zpětných odkazů tímto způsobem zabere jeden večer.

Runbook v pořadí

1. Přidejte tajnou proměnnou

Nastavení repozitáře, pak Tajné proměnné a proměnné, pak Akce. Pojmenujte ji LZ_KEY. Pokud ji vložíte přímo do souboru workflow, změňte klíč ještě dnes.

2. Commitněte skript

Uložte níže uvedený Python jako snap.py. Zapíše data/YYYY-MM-DD/refdomains.json a selže při jakékoli odpovědi, kde ok je false.

3. Commitněte workflow

Použijte níže uvedený YAML. Spusťte jej jednou ručně pomocí spouštěče workflow_dispatch a přečtěte si log, než důvěřujete plánování.

4. Zkontrolujte první soubor

Otevřete JSON. Potvrďte počet řádků proti total a porovnejte číslo s tím, co hlásí volání overview pro vaši doménu.

5. Přidejte upozornění

Selhaný job ve výchozím nastavení pošle e-mail majiteli repozitáře. Nechte to tak. Job, který tiše přestane fungovat, je obvyklý způsob, jak tyto nastavení umírají.

snap.py

Standardní knihovna. Smyčka končí na počtu, nikoli na odhadu.

python

import json, os, sys, datetime, pathlib, urllib.request as u
KEY = os.environ['LZ_KEY']
TARGET = sys.argv[1]
def get(**p):
    q = '&'.join(f'{k}={v}' for k, v in p.items())
    url = f'https://linkzoid.pro/api.php?{q}&key={KEY}'
    with u.urlopen(url, timeout=30) as r:
        return json.load(r)
rows, page = [], 1
while True:
    d = get(action='refdomains', q=TARGET, page=page, per=1000)
    if not d['ok']:
        sys.exit(f'bad response: {d}')
    rows += d['rows']
    if not d['rows'] or len(rows) >= d['total']:
        break
    page += 1
day = datetime.date.today().isoformat()
out = pathlib.Path('data') / day
out.mkdir(parents=True, exist_ok=True)
(out / 'refdomains.json').write_text(json.dumps(rows))
print(len(rows), 'rows, balance', d['_credits'])

.github/workflows/snapshot.yml

Cron v GitHub běží v UTC a může začít pozdě, když jsou runneri vytížení. Nevytvářejte nic, co závisí na minutě.

yaml

name: backlink-snapshot
on:
  schedule:
    - cron: '17 6 * * 1'
  workflow_dispatch:
jobs:
  snap:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: python snap.py example.com
        env:
          LZ_KEY: ${{ secrets.LZ_KEY }}
      - run: |
          git config user.name snapshot-bot
          git config user.email "snapshot-bot@localhost"
          git add data
          git commit -m "snapshot $(date -u +%F)" || exit 0
          git push

Zahradník prořezávající mladý stromek, představující přípravu před spuštěním plánování

Než zapnete plánování

Klíč je v tajných proměnných repozitáře a YAML ho odkazuje pouze jménem.
Soubor workflow je na výchozím vetvi, protože to je kopie, kterou plánování čte.
Ruční běh s workflow_dispatch dokončil a zapsal jednu složku s datem.
Počet řádků v souboru odpovídá celkovému počtu, který API vrátilo pro toto volání.
Job skončí s nenulovým kódem při špatné odpovědi, takže selhání změní běh na červený.

Chyby a opravy

Co se v plánovaném jobu pro zpětné odkazy pokazí jako první
Chyba	Co vidíte	Oprava
Klíč vložený v YAML	Klíč viditelný v historii repozitáře	Změňte ho, přesuňte do `secrets.LZ_KEY`
Podivná minuta jako `0 0`	Běh začne o 20 minut později	Vyberte `17 6`; začátek hodiny je přeplněný
Repozitář nečinný 60 dní	GitHub pozastaví plánování	Commitněte něco, nebo ho znovu povolte v záložce Actions
Smyčka končí pouze na prázdné stránce	Nekonečný běh na limitu stránek	Také zastavte, když `len(rows) >= total`
Kód ukončení ignorován	Zelená fajfka, prázdná složka	Použijte `sys.exit` na `ok: false`
Commit selže při žádné změně	Červený běh pro nic za nic	Přidejte `\|\| exit 0` za commit

Udržení klíče a repozitáře v bezpečí

Klíč je v tomto nastavení jediná věc, za kterou stojí za to se bát. Zacházejte s ním jako s heslem, protože každý, kdo ho má, může utratit váš zůstatek.

Plánované joby tiše unikají. Klíč vložený do logu, workflow zkopírované do veřejného repozitáře nebo bývalý kolega s přístupem pro zápis jsou obvyklé cesty. Zkontrolujte každou z nich jednou za čtvrtletí.

Změňte klíč, když někdo odejde

Když odejde kolega s přístupem, vytvořte nový klíč, aktualizujte tajnou proměnnou a zrušte starý. Poté potvrďte, že další běh projde. Jeden zelený běh po změně je nejlevnější test, jaký během roku uděláte. Zapište si také datum změny do poznámek repozitáře, aby další změna nebyla překvapením.

Omezte, kdo může upravovat workflow

Kdokoli, kdo může upravovat YAML, může vytisknout tajnou proměnnou v běhu. Udržujte přístup pro zápis krátký a kontrolujte změny ve souboru workflow stejně jako kód. Dva lidé s přístupem pro zápis jsou obvykle dostateční pro malý repozitář.

Nikdy netiskněte URL požadavku

Tiskněte zůstatek a počet řádků, nikdy URL požadavku. Klíč cestuje v query stringu, takže řádek ladícího tisku URL zapíše klíč do logu. Pokud musíte sdílet požadavek v issue, nejprve nahraďte klíč zástupným znakem.

Kompas a květináč, naznačující stabilní postup a včasné odhalení problémů

Co snímek je, a co není

To, co dostanete, je měsíční obrázek. Náš vlastní crawler obnovuje index přibližně jednou měsíčně, takže dva pondělní běhy ve stejném měsíci často vrátí stejné řádky. To je očekávané.

Týdenní rytmus funguje. Udržuje zvyk naživu a zachytíte selhání do sedmi dnů místo třiceti. Pokud je odkaz, který jste postavili ve úterý, v pondělí pryč, počkejte na další obnovení, než začnete panikařit.

Když máte tři nebo čtyři složky s datem, přesuňte se k diffu profilu zpětných odkazů v SQLite. Pokud zaseknete na tvrdohlavém kódu odpovědi, tabulka limitu rychlosti uvádí, co každý status znamená pro smyčku.

Ponechte první složku jako základ. Každé další porovnání se vrací k ní a složka pojmenovaná podle data je mnohem snazší důvěřovat než paměť na to, jak čísla vypadala minulou jaro. Zůstaňte konzistentní.

Přidání kotvících textů a top stránek

Jedna akce na soubor udržuje diffy čitelné. Zkopírujte smyčku v snap.py, změňte refdomains na anchors nebo toppages a zapište do druhého souboru. Každá stojí 2 kredity.

Kombinovaný soubor skryje, která část se změnila, a recenzent procházející pull request chce vidět jeden koncept na diff. Ponechte je oddělené. Pokud sledujete tři domény, projděte v workflow krátkým seznamem pomocí matice, aby každý cíl dostal svůj vlastní job a své vlastní selhání.

Kotvící texty jsou druhý soubor s vlastním limitem v diffu, takže je kontrolujte odděleně od odkazujících domén. Každý běh zůstává levný a opakovatelný, což je celý záměr.

Čtení logu běhu

Otevřete log prvního běhu. Udělejte to, než důvěřujete plánování. Hledejte počet řádků, zůstatek a řádek commitu. Pokud chybí kterýkoli ze tří, job udělal méně, než tvrdí. Udržujte také krátkou poznámku o zůstatku při každém běhu, aby byl měsíční výdaj viditelný bez otevírání dashboardu.

Zelená fajfka říká málo. Pouze znamená, že proces skončil čistě. Neříká, že soubor obsahuje správné řádky, proto skript vytiskne svůj vlastní souhrn. Tyto řádky souhrnu ponechte mezi verzemi skriptu nezměněné, aby diff dvou logů ukázal pouze skutečné změny.

Jak vypadá zdravý log

Zdravý běh vytiskne jeden řádek s počtem řádků a zůstatkem kreditů, poté commit s dnešním datem. Cokoli, co zabalí tyto řádky pod další šum, stojí za druhý pohled.

Pochycení tichého selhání

Sledujte prázdnou složku, commit, který se nikdy neobjeví, nebo počet řádků, který se liší od total. Každá z těchto věcí ukazuje na smyčku nebo parse, ne na samotné API. Uložte první zdravý log jako referenci pro budoucí porovnání.

Některá selhání zanechají složku s méně řádky, než je obvyklé. Porovnejte počet s minulým týdnem, než oslavujete zelený běh, protože tichá zkratka vypadá přesně jako tichý měsíc.

Přidání druhého cíle bezpečně

Druhá doména je položka matice, ne kopie celého workflow. Dejte každému cíli vlastní job, aby jedno selhání nezkrylo druhé. Ponechte každý job oddělený. Zkontrolujte, že cesty zahrnují název domény, aby dva běhy nikdy nezapísaly do stejného souboru.

Začněte pouze s druhým cílem. Jakmile jeho složka vypadá správně, přidejte zbytek. Matice, která selže uprostřed, je těžší číst než dva jednoduché běhy.

Pojmenujte složky podle cíle

Dejte doménu do cesty, například data/<domain>/YYYY-MM-DD, a složky zůstanou oddělené, i když dva joby běží ve stejné minutě. Staré složky mohou zůstat tam, kde jsou, protože datum v cestě je usnadňuje hledání.

Použijte stejné pravidlo pojmenování pro každý cíl. Skript pak může vypsat složky bez speciálních případů.

Nejprve naplánujte rozpočet kreditů

Vynásobte volání na cíl počtem cílů, poté zkontrolujte celkem proti svému zůstatku před prvním během. Matice násobí výdaje stejně rychle, jako násobí joby. Zapište očekávaný měsíční celkem do repozitáře vedle workflow. Když zůstatek klesá rychleji, než je tento plán, smyčka pravděpodobně znovu načítá stránky, a můžete ji zastavit před dalším během.

Otázky, které se objeví v prvním týdnu

Mohu to spustit na soukromém repozitáři zdarma?: Obvykle ano, v rámci měsíčních minut, které GitHub dává bezplatným účtům. Job snímku běží výrazně pod minutu, takže týdenní plánování používá malou část. Zkontrolujte aktuální povolení svého plánu, protože GitHub ho občas mění.
Kde by měl být klíč, pokud tlačí několik lidí?: V tajné proměnné organizace nebo repozitáře, nikdy v souborech. Kdokoli, kdo může upravovat workflow, může vytisknout tajnou proměnnou v logu, takže omezte, kdo má přístup pro zápis, a změňte klíč, pokud někdo opustí projekt.
Proč se můj plánovaný běh nespustil?: Tři obvyklé důvody. Soubor workflow není na výchozím vetvi, repozitář byl nečinný 60 dní a GitHub pozastavil plánování, nebo cron string má překlep. Spusťte jej jednou s workflow_dispatch, abyste vyloučili samotný skript.
Jak velké se složky dat stanou?: Malé. Tisíc odkazujících domén je několik set kilobajtů JSON. Rok týdenních souborů pro jednu doménu zůstává výrazně pod sto megabajty, což je pro git v pořádku, i když můžete starší složky komprimovat, pokud vám to vadí.