Jako liitetään, editori avaa tiedoston ja build kulkee silti kannettavalla. Mikään ei ilmoita virheestä, ja juuri se hämmentää. Etäpolku ei ole etätyökaluketju, ja editori, joka pystyy lukemaan tiedoston liitoksen kautta, kutsuu mielellään paikallista kääntäjää sen päälle. Ratkaisu on siirtää työtila, ei vain tavuja.

Liitetty hakemisto ei ole työtila

Liittäminen SSH:n tai SMB:n yli antaa sinulle polun. Tulevatko kääntäjä, build-järjestelmä ja debuggeri etäpuolelta, riippuu siitä, mihin editori päättää ne sijoittaa. Monet asetukset lukevat etätiedostoja ja kääntävät ne paikallisesti ja kaatuvat sitten otsikkotiedostoon, jota on vain palvelimella.

Oire on hienovarainen: build onnistuu osittaisilla tuloksilla tai hajoaa include-polulla, joka näyttää editorissa oikealta.

Todista, mikä host vastaa

Yhdistä oikealla etäistunnolla liitoksen sijaan ja aja sitten kolme vain luku -komentoa istunnon antamassa päätteessä. VS Coden SSH-opas dokumentoi, että yhdistetyn etäikkunan pääte ajetaan etähostilla ja että sama istunto kuljettaa debuggausta. Hanki ensin hyväksyntä etäkomponenteille, jos organisaatio rajoittaa niitä.

hostname nimeää koneen, jolla olet, pwd näyttää, missä työtila todella sijaitsee, ja command -v c++ tulostaa kääntäjän, jonka komentotulkki ajaisi. Kaikkien kolmen vastauksen pitäisi kuvata palvelinta, ei kannettavaa.

Ne eivät todista, että versio tai build-kokoonpano on oikea. Vertaa sitä projektin omiin ohjeisiin erillisenä vaiheena.

Seuraa yhtä muutosta buildin ja debuggaamisen läpi

Tee pieni muutos etätyötilassa ja tallenna se sinne. Aja dokumentoitu build samasta hakemistosta ja varmista, että tulos heijastaa muutostasi eikä vanhempaa kopiota jossain muualla. Käynnistä sitten debuggeri saman etäistunnon kautta niin, että binääripolku ja työhakemisto osoittavat palvelimen build-puuhun. Lähdepolkujen yhteensopivuus on tärkeää, koska debuggeri, joka ratkaisee muutoksesi kannettavan poluksi, debuggaa eri tiedostoa.

Jos debuggauksen kohde ilmoittaa poluista, jotka alkavat paikallisesta kotihakemistostasi, käynnistyskonfiguraatio ajattelee yhä paikallisesti.

Verkkoriippuvuudet pysyvät hostilla

Build-hostilla aloitettu paketinhaku, git-toiminto tai testiajo käyttää kyseisen hostin verkkoa ja tunnuksia, ei kannettavasi VPN-istuntoa. Se, että kannettava tavoittaa yksityisen pakettipeilin, ei kerro mitään siitä, pystyykö palvelin. Jos build tarvitsee rekisterin, palvelin tarvitsee reitin sinne, ja se on palomuurikeskustelu, ei editorin asetus.

Sama pätee päinvastoin testisovelluksiin. Palvelimella olevan palvelun tavoittaminen selaimestasi on erillinen yhteys, joka tarvitsee hyväksytyn yksityisen polun tai rajoitetun edelleenohjauksen, ei avointa kuuntelijaa.

Katkaise yhteys menettämättä työtä

Tallenna ja committaa, tai ainakin kirjaa työpuu, ennen kuin yhteys katkeaa. Etämuokkausistunto ei lupaa, että käynnissä oleva build tai tallentamaton puskuri selviää verkkokatkoksesta. Kaikelle, jonka on elättävä istuntoasi pidempään, käytä projektin tukemaa työ- tai istuntovirtaa.

Työnjako on silloin selvä: kannettava on käyttöliittymä, palvelin omistaa työtilan ja työkaluketjun, ja VPN tarjoaa reitin. Tiedostojen siirtäminen ja buildin siirtäminen ovat kaksi erillistä päätöstä.

Aiheeseen liittyvät artikkelit