Badges mogelijk maken die niet per run vervangen hoeven te worden #267
Comments
|
Besproken. Geen datum/tijd in badge & UI aandacht qua snippets op de detail pagina. We moeten nog wel goed nadenken over of per-run badges wel of niet wenselijk zijn, of wat we alleen de laatste status-badge moeten willen. Ook moeten we bedenken of we qua structuur niet meer nadruk moeten leggen op de test scenario's, en dat je een overzicht hebt van de laatste run-status van alle test-scenario's (minder nadruk op de historie, want die is een stuk minder relevant). To be continued... |
|
@HenriKorver @alextreme moet er een zelfde soort structuur komen (dus een veranderende badge en een statische badge) voor consumer sessions? |
|
Keuze is hiervoor aan de PO, ik vind de meerwaarde van dit aanpassen aan de consumer-kant beperkt. |
|
Ik begrijp de vraag niet want bij consumers heb je geen aparte scheduled tests. Dus hier zou het probleem helemaal niet moeten spelen. |
|
Eigenlijk begrijp ik het probleem ook niet zo goed aan de provider-kant. Waarom zou je daar twee badges (veranderende en statische badge) moeten onderscheiden bij scheduled tests? Ik zou alleen de badge met het meest recente resultaat ondersteunen. Dus als de laatste test via de automatische schedule is uitgevoerd dan refereert de badge naar dat resultaat en als de laatste test handmatig is opgestart binnen dezelfde sessie als de scheduled test dan refereert de badge naar het handmatige resultaat. |
|
By the way, op productie is de badge steeds grijs en inaccessible: |
|
@HenriKorver deze issue wordt veroorzaakt door de code die de datumtijd in de badge zette, maar doordat de datumtijd toch weer uit de badge gehaald zal worden, zal deze issue ook gelijk opgelost worden. Zodra deze commit naar productie gedeployed is, zal ik een seintje geven en kun je het nog eens proberen |
|
@HenriKorver er is weer geployed, dus nu zou de badge op https://api-test.nl/server/scheduled/ wel goed moeten zijn |
|
@stevenbal Yes, dank! Dat laatste probleem is nu opgelost. @stevenbal en @alextreme Echter ik begrijp nog steeds niet waarom er twee badges worden onderscheiden (veranderende en statische badge). Zie ook mijn eerdere opmerkingen. Kunnen jullie mij dit proberen uit te leggen? |
|
En zelfs als je twee badges zou willen ondersteunen, dan lijkt het nu niet goed te gaan. In sessie 299 is de eerste badge groen en de tweede rood. Echter ze zouden allebei rood moeten zijn. |
|
@HenriKorver @alextreme ik denk dat inderdaad de badge die de meest recente status weergeeft het belangrijkst is, maar ik denk dat het toch ook handig is om te zien wat de status was bij verschillende runs van hetzelfde testscenario (je kunt bij Jenkins of Travis ook status van builds uit het verleden terugzien). Als we de badge die weergegeven wordt bij de lijst met provider runs vervangen door de meest recente badge, maar dan kun je wel een mismatch krijgen tussen de status van de run en de badge die erachter staat (in het voorbeeld hierboven dus bij #299 een groen vinkje maar een badge die zegt failed). Misschien moeten we de weergave op het webinterface aanpassen, zodat je bijv eerst een lijst krijgt met de test scenarios voor de ingelogde user (+ de meest recente badge) en als je dan doorklikt op een bepaald scenario dat je dan de lijst met provider runs voor dat scenario te zien krijgt (+ status en bovenaan dan 1x de meest recente badge)? |
|
Eens met je voorstel om uiteindelijk het webinterface aan te passen zodat eerst alles op scenario-niveau gegroepeerd wordt en je erna kunt doorklikken naar alle provider runs die doorlopen zijn van nieuw naar oud (als het ware de historie van de testresultaten) ongeacht of die met de hand, via de api of met een schedule zijn opgestart. Alleen moeten we dan eerst het probleem van de scheduled tests oplossen. Immers voor elke provider run die door de scheduled test (automatisch) is opgestart moet dan ook een sessie id aangemaakt worden. zodat je er expliciet naar kunt refereren. Nu hebben de scheduled tests zelf ook een sessie id maar dat is eigenlijk heel iets anders en zou hernoemt moeten worden naar schedule id of iets dergelijks. |
|
Dus eigenlijk zou er een soort model tussen test scenario en provider run moeten zitten voor de scheduled tests? Zodat er dan voor elke scheduled test een provider run wordt aangemaakt die verwijst naar dat model, zodat je weet bij welk schedule de run hoort. |
|
Helemaal correct |
|
Besproken. Qua naamgeving en usability nog wel enkele verbeteringen mogelijk, Henri neemt ook even de tijd om op basis van staging.api-test.nl met verdere feedback te komen. Qua badges: je bent alleen geintereseerd in de laatste badge voor een bepaalde environment. |
|
Besproken. De scheduled badges verversen inmiddels zoals verwacht. Wel had Henri nog de wens uitgesproken qua URL waarop je doorklkt te veranderen, zie #304 |
Issue is door @stevenbal voorzien na het voorwerk voor #263
We hebben nu 2 soorten provider runs: eenmalige en scheduled. Beide hebben een badge.
Bij de scheduled runs wordt de badge automatisch vervangen (want de oude status wordt ververst wanneer de run nogmaals wordt uitgeverd).
Voor de eenmalige runs is de badge persistent: de status wordt bepaald door de eenmalige run.
In #263 heeft @joeribekker het echter over het integreren van de (eenmalige) runs via de ATP API in Travis en het daarna publiceren van een badge op Github. Echter, hiervoor zou momenteel elke keer de badge vervangen moeten worden in de Readme (want voor het tonen van de badge wordt de UUID van de sessie gebruikt).
Een mogelijke oplossing hiervoor heeft @stevenbal voorgesteld door voor de eenmalige provider runs een badge te gebruiken die altijd de laatste status weergeeft van de combinatie van (Test scenario + Gebruiker) in plaats van de UUID van de sessie. Hiermee zou je een badge kunnen publiceren met de meest recente test scenario status van jouw account.
Keerzijde hiervan is, als je dezelfde scenario op meerdere verschillende URLs uitvoert, dat dan de 'badge' voor je scenario varieert. Je zou om dit probleem te voorkomen kunnen werken met de combinatie van (Test scenario + Gebruiker + hash van de parameters). Misschien maken we het dan wel iets te ingewikkeld, maar dan krijg je in ieder geval dat een badge wat via een CI loopt de actuele stand-van-zaken weergeeft.
The text was updated successfully, but these errors were encountered: