Implementeren met Zinnector®: koppelen, controleren, pushen

Zodra een project lokaal draait, brengen vier commando's het naar een live site op Zinn Digital®-hosting: meld u aan, koppel het project aan een hostingslot, lees de pre-flight en push. Dit artikel behandelt elk commando, wat het weergeeft en de commando's die u daarna gebruikt — hernieuwde implementaties, implementatiegeschiedenis en build-logs.

Aanmelden met een API-sleutel

Maak een sleutel aan in het dashboard onder Instellingen → API-sleutels, en voer vervolgens uit:

zinnector login

De sleutel wordt ingevoerd bij een prompt — deze wordt nooit geaccepteerd op de opdrachtregel, zodat deze niet in uw shellgeschiedenis of een proceslijst terecht kan komen. In CI kunt u deze via een pipe doorsturen: echo "$ZINN_API_KEY" | zinnector login --profile ci, of stel ZINNECTOR_TOKEN in en sla login volledig over. De sleutel wordt geverifieerd voordat deze wordt opgeslagen, en opgeslagen met bestandsmodus 600. zinnector whoami --scopes toont bij welke organisatie u bent aangemeld en welke machtigingen de sleutel bevat; een sandbox-sleutel wordt als zodanig gelabeld.

Koppel het project aan een slot

zinnector link                                   # pick a site from a list
zinnector link example.com --repo acme/site --branch main

link schrijft de id van de site naar zinnector.json en verbindt, tenzij u --no-repo meegeeft, de git-remote van het project met de site op het platform, zodat een push het implementeert. Commit zinnector.json: een collega die de repository kloont, implementeert vervolgens naar dezelfde locatie zonder instructies vooraf. Het bevat geen geheimen.

Lees de pre-flight

zinnector check

Dit is het commando waar de CLI voor bestaat. Het vergelijkt uw project met het slot waarnaar het op het punt staat te worden geïmplementeerd en toont elke mismatch — en elke vergelijking die niet kon worden gemaakt:

• PHP-versie, waarbij een verschil in hoofdversie als hoog wordt geclassificeerd omdat dit een site geheid breekt, en een klein verschil lager wordt ingeschaald, omdat het als kritiek aanmerken van alles mensen leert de waarschuwing te negeren.
• Of het slot kan overschakelen naar de versie waarop u hebt gebouwd, of de PHP van het slot voorbij het einde van de levenscyclus is, en of de machine de versie heeft toegepast of dit alleen te horen heeft gekregen.
• De grootte en het aantal bestanden van uw project vergeleken met de daadwerkelijk overgebleven schijf- en inode-ruimte op het slot — een WordPress-structuur kan door het maximale aantal bestanden heen zijn terwijl het ruim onder de schijflimiet blijft.
• De WordPress-versies aan beide kanten, of het slot klaar is met inrichten, en of er een repository is gekoppeld om naar te pushen.

Het waarschuwt; het blokkeert nooit. Elke bevinding kan worden genegeerd met zinnector push --force, omdat u zaken over uw eigen site weet die een controleprogramma niet weet. Een vergelijking die niet kon worden gemaakt, wordt gerapporteerd als onbekend, nooit als geslaagd, en het overzicht vermeldt altijd hoeveel er waren. Standaard is de lokale PHP-versie degene die is gedeclareerd in zinnector.json; --probe start de lokale runtime op en meet deze in plaats daarvan. --strict sluit ook af met een niet-nulwaarde bij onbekende waarden, wat een CI-gate vereist.

Push

zinnector push

push voert de pre-flight uit, pusht uw commits, triggert de implementatie en volgt deze tot voltooiing, waarbij de definitieve status en de geïmplementeerde commit worden weergegeven. --dry-run doet alles behalve de implementatie; --no-wait triggert deze en sluit af; --no-git implementeert wat het platform al heeft zonder te pushen. Als de geïmplementeerde commit niet degene is die zojuist is gepusht, wordt dit aangegeven.

Wanneer er iets misgaat

zinnector deploys example.com        # deploy history — status, commit, trigger, message
zinnector logs example.com --build   # the build log of the most recent deploy
zinnector logs example.com --error   # the site's error log
zinnector deploy example.com         # redeploy what the platform already has
zinnector ai "why is my deploy failing?"

zinnector ai draait op het platform binnen uw eigen account, zodat het dezelfde implementatiegeschiedenis en logs kan inzien. Vanuit een project verstuurt het de structuur van het project — mapnamen, versies en de site-id — en nooit bestandsinhoud.

Gerelateerd

• Aan de slag · Lokale ontwikkeling · Commando-overzicht · Probleemoplossing