GitHub brengt eerste stabiele versie van Command Line Interface-tool uit

GitHub heeft de eerste stabiele versie van zijn CLI-tool uitgebracht. Met GitHub CLI kunnen gebruikers hun repositories volledig vanuit een terminal beheren. De software is gratis, opensource, en beschikbaar op Linux, macOS en Windows.

GitHub maakte versie 1.0 eerder deze week beschikbaar. Een bètaversie van de Command Line Interface-tool werd in februari al geïntroduceerd. Met de CLI-tool kunnen gebruikers GitHub volledig vanuit hun terminal gebruiken door middel van verschillende commando's. Gebruikers kunnen met dergelijke commando's bijvoorbeeld nieuwe repositories maken en bestaande repo's klonen, issues bekijken, pull requests beheren en merges uitvoeren.

GitHub CLI moet onder andere context switching verminderen. Softwareontwikkelaars die vanuit een terminal werken, hoeven met de tool minder te wisselen tussen hun terminal en de website van GitHub. Dat moet de efficiëntie ten goede komen. Gebruikers kunnen met CLI ook de GitHub-API gebruiken om aliassen voor commando's in te stellen en 'vrijwel alle acties te scripten en automatiseren'. De CLI-tool biedt verder ondersteuning voor repositories op GitHub Enterprise Server 2.20 of hoger, naast repo's op de reguliere website van de dienst.

Reacties (49)

Gebruik de GitHub CLI een aantal maanden (destijds in beta). Doe voor Mautic veel PR's controleren; het grootste deel hiervan komt van externe contributors die vanuit hun eigen forks werken. Nu kun je met de CLI heel eenvoudig "gh pr checkout <ID>" doen waardoor je direct lokaal in de branch van die persoon zit (terwijl die in feite dus in een fork heeft gewerkt). Ideaal zo zijn er ongetwijfeld nog veel meer handige use cases.

Over het algemeen hoef je je GIT repo maar een keer in te richten. Die enkele keer dat je een nieuwe aan moet maken is het niet echt een issue, maar goed. Voor het CI/CD gedeelte, geen idee of je dat in Github kunt doen, ik gebruik Azure en die trekt alles uit Github zonder dat daar een CLI voor nodig is.

Git is een stuk meer dan git commit en push/pull en Github is een stuk meer dan Git.

Met name voor het hele proces rond Pull Requests (dus ook het forken) lijkt me een CLI erg handig.

CI/CD kan via de API grotendeels prima, het is namelijk allemaal gewoon HTTP verkeer. Het enige waar ik met Jenkins tegenaan liep is file uploads. Via Jenkins' eigen httpRequest kun je niet (lekker) willekeurige binary files uploaden, dat heb ik dus met een curl command gedaan.

Een release aanmaken via de REST API:

• HTTP POST request met JSON body voor de release zelf.
• Voor elke file file, HTTP POST request met file body. Elke content type is mogelijk.

Een release aanmaken via deze CLI, als ik het goed heb gelezen:

• gh release create <tag> [<files>...] [flags]

Hierbij zitten <tag> en [flags] al in de JSON body, de files komen er dus bij. Wat ik wel mis is custom content types; dat heb ik nog niet teruggevonden.

De flags zijn trouwens wel logischer genaamd:

• target_commitish -> --target
• name -> --title of -t
• body -> --notes of -n; of --notes-file of -F om een file te gebruiken
• draft -> --draft of -d
• prerelease -> --prerelease of -p

Issues maak je volgens mij altijd aan via de site ;-)

Nu dus niet meer...
https://cli.github.com/manual/gh_issue_create

ik gebruik Azure en die trekt alles uit Github zonder dat daar een CLI voor nodig is.

Ik neem aan dat je hier iets als App Services mee bedoelt? De CLI zit qua functionaliteit niet in de space tussen Git <-> Applicatie maar vooral tussen dev/team <-> Git.

Lijkt me en handige tool, maar ben wel een beetje bang voor vendor lock-in. Ik zou ook niet weten of dingen als het aanmaken van een repo en het maken van pull requests aanbiederonafhankelijk te maken zijn.

Er is een rede waarom de CLI tool uitgebracht wordt onder de MIT licentie. Niks weerhoudt ze (Microsoft) ervan om de voorwaarden later aan te passen. De CLI koppelt met gesloten server-side systemen dus het is een tekstboek voorbeeld de Tweede E.

Elke auteur kan ten alle tijden de licentie van zijn/haar code veranderen, ook GPL of zelfs Public Domain. Het helpt alleen niet zoveel, want daarmee wordt de vorige licentie niet ineens ongeldig (misschien tenzij dit als clausule is opgenomen, maar daar zullen niet veel mensen mee akkoord gaan).

Ik wist eerlijk gezegd niet dat de tool onder MIT werd uitgebracht. Dat is enigszins hoopvol in ieder geval.

PS: Ben het niet eens met je -1 moderatie, maar ik kan niet en reageren en je anders modereren, sorry.

[Reactie gewijzigd door jimshatt op 21 september 2020 01:21]

Het probleem is iets complexer dan simpelweg de MIT licentie gebruiken. Het probleem ontstaat omdat Microsoft in de toekomst prima een versie kan uitrollen met extra functionaliteit, welke alleen op hun platform werkt, zonder MIT licentie.

Een voordeel van een licentie zoals de GPL, is dat je niet zomaar kan stoppen met de GPL. Met de MIT kan dat juist super makkelijk, en daarom is het een risico.

Als je echt denkt dat dit met de 2e e te maken heeft heb je wat mij betreft echt een alu hoedje op of je hebt de afgelopen jaren onder een steen geleefd.

Microsoft is er niets aan gelegen om dit stuk te maken in de long run. Github is hun toekomst rondom proposities van software development en dit willen ze gebruiken om meer Azure te pushen uiteindelijk.

Deze cli onder MIT is gewoon zodat er weinig gezeik is als je dit gaat extenden voor eigen gebruik door bijvoorbeeld enterprises.

Dat is niet correct. Als ik nu een werk onder de GPL uitbreng kan ik morgen een nieuwere versie onder een andere (propriëtaire) licentie uitbrengen. Jij behoudt het recht om de oude versie onder de GPL te gebruiken maar je hebt nog steeds geen rechten op mijn nieuwe versie.

Dat kan ik, omdat ik de auteur ben. Het is een ander verhaal als ik software van een ander probeer uit te geven onder een andere licentie. Dat kan wel met MIT, maar niet met GPL. Dat is hier niet van toepassing omdat Microsoft (vermoed ik) alle auteursrechten op deze tool heeft. Dus GPL of MIT maakt niet uit, zij mogen morgen de licentie aanpassen als ze dat willen.

GIT blijft git. Als github van git afstapt (git is GPL, dus ze moeten de tool Open Source houden als ze git willen blijven gebruiken) wens ik ze succes. Git is bewezen super robuust en stabiel te zijn (net als linux). Alternatieven minder

Hij doelt op een vendor lock-in naar Github, bijv. aanmaken pull request.

linux is vele malen stabieler dan windows.

er zit een reden achter dat 500 van de 500 top 500 supercomputers linux draaien,
dat 70% van alle web servers linux draaien,
dat linux het meest gebruikte OS op azure is.

alleen BSD is stabieler dan linux, maar BSD heeft minder applicatie support.

ik hoop dat jouw opmerking een grap is, want hoewel linux op de desktop maar 4% is, is het op de server markt (waar stabiliteit boven "oh zo ging het altijd" gaat) is linux veruit de grootste.

de enige reden dat het op desktop niet groot is, is dat de gemmidelde henk niet wilt wisselen, want "het is anders dan normaal".

overigens vind ik het prima dat linux zo klein is op de desktop. Linux zal ook zeker klein blijven, want er zit geen groot bedrijf achter, en 90% van de populatie zal het een worst wezen welk OS draait, zolang ze maar op facebook kunnen komen

en ja, ik gebruik zelf linux. al 3 jaar 100% van de tijd. ik ben in ongeveer 2 maand van "oh, ubuntu is wel grappig" naar "ik gebruik manjaro fulltime, geen windows meer voor mij" gegaan. (nu ruim 2 jaar een void linux user.)

[Reactie gewijzigd door dec0de op 20 september 2020 21:58]

Ik ben ook wel fan van *nix hoor, maar ik kan mij in heel je verhaal niet vinden.
De argumentaties die je aanhaalt hebben naar mijn inziens geen snars met stabiliteit te maken. Je moet ook niet vergeten dat je aardig wat zaken net zo goed visa-versa kan verwoorden. Immers heb ik nog maar bar weinig corporates gezien die geen exchange of AD gebruiken. Er is een mega groot segment dat net zo goed volledig en stabiel op Windows draait.

Ik heb er zelf nooit zo veel bij stil gestaan waarom ik *nix gebruik. Het komt meer voort uit compatibliteit. Je noemt webservers op en apache/nginx hebben gewoon mijn voorkeur over windows IIS bijvoorbeeld. Daarop volgent m.b.t. die compatibliteit is het de aanpasbaarheid wat gewoon heel prettig is voor in elk geval mijn use-cases.

En dat is volgens mij ook het argument voor supercomputers, je kan het OS dermate aanpassen dat je alleen het broodnodige gebruikt en op jouw manier. Dat lukt domweg niet met Windows of elk ander proprietary OS. Echter heeft dat nogmaals niets met stabiliteit te maken.

Ja, maar die bedrijven proberen niet linux door de strot van consumenten te douwen. Alleen google met android en chromeOS, maar chromeOS is net zo veel linux als chromr KHTML is. Het lijkt wel wat op elkaar onder de motorkap, maar niet veel buiten de motorkap

Dit is meer om richting github acties te ondernemen vanuit je ci/cd pipeline. Dus je kan automatisch commits taggen, pull requests sluiten en misschien zelfs nieuwe commits maken(niet doen lol).

Taggen en commits maken kan allang via de reguliere git terminal. Alleen prs sluiten is geloof ik iets wat nog niet kon (van jou voorbeelden).

Mij lijkt het lokaal juist handig. Push een feature-branch en maak gelijk een PR aan bijv.

Waarom is nieuwe commits maken "lol"? Ik doe dit bijv. voor de Gitops flow waarbij een pipeline de Docker image digest automatisch update in het Kubernetes manifest.

Ik ga hier eens mee spelen, klinkt zeker interessant. Al ben ik ergens bang dat het meer een gimmic wordt dan echt een veel gebruikte tool. Ik spendeer over het algemeen veel liefde en tijd aan een PR. En heb toch het idee dat deze tool meer op snelheid is gebaseerd, niet mijn top requirement voor het maken van een goede PR

Ik denk dat je hier vooral leuke scripts mee zou kunnen maken. Aangezien je zonder deze tool in zou moeten loggen via Oauth (waarschijnlijk gebruikt deze tool dat dan of de ingebouwde git auth manager van windows). En dan zou je makkelijkere scripts kunnen maken, zoals bijvoorbeeld het publiceren van een repo online (bijvoorbeeld bij een initialisatie van een nieuw project). Hoef je niet overal je credentials achter te laten, want die tool regelt dat voor je.

(oeps per ongeluk gecomment)

Hoe verwijder ik een comment?

[Reactie gewijzigd door kornelisjann op 20 september 2020 17:38]

gh rm comment

Command Line Interface Tool. Ergens vraag ik me af of een nerdje die term gekozen heeft voor de afkorting

Waarom heb ik het gevoel dat deze tool een beetje lijkt op de oude EEE strategie van Microsoft?

Omdat ze git geembraced hebben in zomer 2018 en nu aan het extenden zijn ?

Ik ben voorzichtig optimistisch over microsoft. Maar nu lijken ze de EEE ook op linux toe te passen (DX12 alleen op WSL(2) ) ben ik langzaam maar zeker steeds voorzichtiger

AWS heeft ook een CLI tool en heb tot dusver geen berichten voorbij zien komen dat dit op grote schaal misbruikt wordt door hackers.

Sterker nog, deze CLI is denk ik gebouwd bovenop de al lang bestaande REST API van GitHub. Dus als de theorie op gaat dat dit makkelijker wordt voor hackers om in te breken zou dat al lang gebeurd zijn toch?

Het lijkt mij wel het meest waarschijnlijk dat deze CLI een schil is rond de REST API, puur om hergebruik mogelijk te maken. Volgens mij zijn de meeste CLI tools waar ik de laatste jaren mee gewerkt heb niets meer dan een schil om REST endpoints (al promoten veel bedrijven dan alleen de CLI versie i.p.v. dat je documentatie kan krijgen om zelf iets te maken).

Gast, waar heb je het over?

Of je nou een browser of een CLI tool gebruikt, wat is het verschil behalve hoe het eruit ziet? Of ik nou een PR aanmaak via de CLI/API of door in de browser rond te klikken, zie op gebied van veiligheid geen verschil.

Ik weet niet precies waar je het over hebt. Niet lullig bedoeld maar ik kan er ook niet echt omheen draaien: GIT heeft niks met sysadmins of hacken te maken. Het is heel simpel gezegd een versiebeheersysteem voor o.a. software-ontwikkeling en niet veel meer dan dat.

Deze specifieke tool stelt GitHub-gebruikers in staat om hun dagelijkse taken vanuit de CLI te doen, in plaats van de site, 3rd-party tools en de al bestaande API. Niet heel spannend op risico-gebied.

Deze tool gebruikt gewoon oauth (heb de code gister nog doorgenomen op dit vlak) en is dus niet minder veilig dan he browser. En veiliger dan random guess want op de oauth endpoints van GitHub zit gewoon rate limiting en abuse filters.

2fa is ook gewoon Mogenlijk in een cli en zodra je authenticated bent mag je Idd de standaard dingen doen waar jij recht op hebt om te doen.

Verder zijn niet alleen sysadmins “verslaafd” aan de terminal. Eigenlijk iedereen die veel remote werkt gebruikt de terminal veel. Ook poweruser & tweakers zijn vaak fan van de terminal. Je bent namelijk meestal sneller en preciezer met de terminal. (Misschien het eerst eens het een tijdje proberen voordat je het afkraakt)

Nog even los van het punt dat het voor security echt nul verschil maakt of je nu vanaf de vlo werkt of vanuit je browser: waarom zouden de acties die hierboven in het artikel omschreven worden interessant zijn voor CI/CD?

Maar hoe? Het gebruikt gewoon APIs die er al waren.