Távoli C++ build VPN-en át: tartsd az eszközláncot a hoszton

A megosztás csatolódik, a szerkesztő megnyitja a fájlt, a build pedig továbbra is a laptopon fut. Semmi nem jelez hibát, és pont ez teszi zavaróvá. Egy távoli útvonal nem távoli eszközlánc, és egy szerkesztő, amely csatoláson át olvas fájlt, szívesen meghívja rá a helyi fordítót. A megoldás a munkaterület áthelyezése, nem csak a bájtoké.

A csatolt könyvtár nem munkaterület

Az SSH vagy SMB fölötti csatolás útvonalat ad. Hogy a fordító, a buildrendszer és a hibakereső a távoli oldalról jön-e, azon múlik, hol dönt úgy a szerkesztő, hogy futtatja őket. Sok beállítás távoli fájlokat olvas és helyben fordítja őket, majd elhasal egy fejlécfájlon, amely csak a szerveren létezik.

A tünet finom: a build részeredményekkel sikerül, vagy eltörik egy include-útvonalon, amely a szerkesztőben helyesnek látszik.

Bizonyítsd, melyik hoszt válaszol

Csatolás helyett valódi távoli munkamenettel kapcsolódj, majd futtass három csak olvasó parancsot a munkamenet által adott terminálban. A VS Code SSH-útmutatója dokumentálja, hogy a csatlakoztatott távoli ablak terminálja a távoli hoszton fut, és ugyanaz a munkamenet viszi a hibakeresést. Ha a szervezet korlátozza a távoli komponenseket, előbb kérj rájuk jóváhagyást.

hostname megnevezi a gépet, amelyen vagy, pwd megmutatja, hol él valójában a munkaterület, és command -v c++ kiírja a fordítót, amelyet a shell futtatna. Mindhárom válasznak a szervert kell leírnia, nem a laptopot.

Ezek nem bizonyítják, hogy a verzió vagy a buildkonfiguráció helyes. Ezt külön lépésként vesd össze a projekt saját utasításaival.

Kövess végig egy módosítást a builden és a hibakeresésen

Végezz kis módosítást a távoli munkaterületen, és mentsd el ott. Futtasd a dokumentált buildet ugyanabból a könyvtárból, és igazold, hogy a kimenet a módosításodat tükrözi, nem egy régebbi példányt máshol. Ezután indítsd el a hibakeresőt ugyanazon a távoli munkameneten át, a bináris útvonalával és munkakönyvtárával a szerver buildfájába mutatva. Az egyező forrásútvonalak számítanak, mert a hibakereső, amely a módosításodat laptop-útvonalhoz rendeli, más fájlt hibakeres.

Ha a hibakeresési cél olyan útvonalakat jelent, amelyek a helyi saját könyvtáraddal kezdődnek, az indítási konfiguráció még mindig helyben gondolkodik.

A hálózati függőségek a hosztnál maradnak

A buildhoszton indított csomaglekérés, git-művelet vagy tesztfuttatás annak a hosztnak a hálózatát és hitelesítő adatait használja, nem a laptopod VPN-munkamenetét. Az, hogy a laptop elér egy privát csomagtükröt, semmit nem mond arról, hogy a szerver eléri-e. Ha a buildnek regiszter kell, a szervernek útvonal kell hozzá, és ez tűzfalbeszélgetés, nem szerkesztőbeállítás.

Ugyanez fordítva igaz a tesztalkalmazásokra. Egy szerveren futó szolgáltatás elérése a böngésződből külön kapcsolat, amely jóváhagyott privát útvonalat vagy korlátozott továbbítást igényel, nem nyitott figyelőt.

Bontsd a kapcsolatot a munka elvesztése nélkül

Ments és commitolj, vagy legalább rögzítsd a munkafát, mielőtt a kapcsolat megszakad. Egy távoli szerkesztési munkamenet nem ígéri, hogy egy futó build vagy egy nem mentett puffer túléli a hálózatkimaradást. Mindenhez, aminek a munkamenetednél tovább kell élnie, használd a projekt által támogatott feladat- vagy munkamenet-folyamatot.

A munkamegosztás ekkor egyértelmű: a laptop felület, a szerver birtokolja a munkaterületet és az eszközláncot, a VPN pedig adja az útvonalat. A fájlok mozgatása és a build mozgatása két külön döntés.