Implementeren met Zinnector®: koppelen, controleren, pushen

Zodra een project lokaal draait, zijn er vier commando's nodig om het naar een live website te brengen op Zinn Digital®-hosting: inloggen, het project koppelen aan een hosting-slot, de pre-flight lezen en pushen. Dit artikel behandelt elk commando, wat het weergeeft en de commando's die u daarna gebruikt: herimplementaties, implementatiegeschiedenis en build-logs.

Inloggen met een API-sleutel

Maak een sleutel aan in het dashboard onder Instellingen → API-sleutels en voer vervolgens het volgende 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 procesoverzicht terechtkomt. In CI kunt u deze doorpipe: 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 ingelogd en welke machtigingen de sleutel heeft; een sandbox-sleutel wordt als zodanig gelabeld.

Het project koppelen aan een slot

zinnector link                                   # selecteer een website uit een lijst
zinnector link example.com --repo acme/site --branch main

link schrijft de ID van de website naar zinnector.json en verbindt, tenzij u --no-repo opgeeft, de git-remote van het project met de website op het platform zodat een push deze implementeert. Commit zinnector.json: een collega die de repository klonet, implementeert vervolgens op dezelfde locatie zonder dat dit hoeft te worden uitgelegd. Het bevat geen geheimen.

De pre-flight lezen

zinnector check

Dit is het commando waarvoor de CLI bestaat. Het vergelijkt uw project met het slot waarop het wordt geïmplementeerd en geeft elk verschil weer — en elke vergelijking die niet kon worden gemaakt:

• PHP-versie, waarbij een verschil in hoofdversie als hoog wordt aangemerkt omdat dit betrouwbaar een website laat vastlopen en een klein verschil lager wordt beoordeeld, omdat alles als kritiek beoordelen ertoe leidt dat mensen de waarschuwing overslaan.
• Of het slot kan overschakelen naar de versie waarop u heeft gebouwd, of de PHP van het slot het einde van zijn levensduur heeft bereikt, en of de machine de versie heeft toegepast of dat dit slechts is opgedragen.
• De grootte en het aantal bestanden van uw project ten opzichte van de schijf- en inode-capaciteit die daadwerkelijk over is op het slot — een WordPress-boomstructuur kan zonder bestanden komen te zitten terwijl deze 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 overschreven met zinnector push --force, omdat u dingen weet over uw eigen website die een checker niet weet. Een vergelijking die niet kon worden gemaakt, wordt gerapporteerd als onbekend, nooit als geslaagd, en de samenvatting 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 foutcode bij onbekenden, wat gewenst is voor een CI-poort.

Pushen

zinnector push

push voert de pre-flight uit, pusht uw commits, activeert de implementatie en bewaakt deze tot de voltooiing, waarbij de eindsuspend en de geïmplementeerde commit worden weergegeven. --dry-run doet alles behalve de implementatie; --no-wait activeert 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        # implementatiegeschiedenis — status, commit, trigger, bericht
zinnector logs example.com --build   # het build-logboek van de meest recente implementatie
zinnector logs example.com --error   # het foutenlogboek van de website
zinnector deploy example.com         # herimplementeer wat het platform al heeft
zinnector ai "why is my deploy failing?"

zinnector ai draait op het platform voor uw eigen account, zodat het dezelfde implementatiegeschiedenis en logboeken kan inzien. Vanuit een project stuurt het de vorm van het project mee — mapnamen, versies en de website-ID — en nooit de bestandsinhoud.

Gerelateerd

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