search

RFD-FHEM / RFFHEM

Counterpart of SIGNALDuino, it's the code for FHEM to work with the data received from the uC
GNU General Public License v3.0
44 stars 33 forks source link

Update json testdata to new schema #1135

Closed sidey79 closed 1 year ago

sidey79 commented 1 year ago

Test data is taken from another repository. Since schema update in the other repository, the tests are not running as expected.

Test data is taken from this repository if testdata is available. If there is no testdata avaailable, testdata is loaded from url if specified and module is installed.

hopefully not

codecov[bot] commented 1 year ago

Codecov Report

Merging #1135 (2d9a139) into master (946f0df) will increase coverage by 1.20%. The diff coverage is 83.83%.

@@            Coverage Diff             @@
##           master    #1135      +/-   ##
==========================================
+ Coverage   65.63%   66.83%   +1.20%     
==========================================
  Files         138      135       -3     
  Lines        9882     9824      -58     
  Branches     1572     1570       -2     
==========================================
+ Hits         6486     6566      +80     
+ Misses       2137     1966     -171     
- Partials     1259     1292      +33
Flag Coverage Δ
fhem 56.31% <83.83%> (-1.60%) :arrow_down:
modules 66.83% <83.83%> (+1.20%) :arrow_up:
perl 90.46% <ø> (+0.12%) :arrow_up:
unittests 66.83% <83.83%> (+1.20%) :arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
t/FHEM/10_FS10/09_ParseData.t 94.11% <ø> (ø)
t/FHEM/10_SD_GT/09_parseData.t 94.11% <0.00%> (ø)
t/FHEM/10_SD_Rojaflex/09_autocreate_devices.t 100.00% <ø> (ø)
t/FHEM/14_BresserTemeo/09_autocreate_devices.t 100.00% <ø> (ø)
t/FHEM/14_SD_UT/01_attr.t 100.00% <ø> (ø)
t/FHEM/14_SD_WS/09_autocreate_devices.t 100.00% <ø> (ø)
t/FHEM/14_SD_WS09/02_SD_WS09_WindDirAverage.t 100.00% <ø> (ø)
t/FHEM/10_SD_Rojaflex/09_parseData.t 94.11% <66.66%> (-4.30%) :arrow_down:
lib/Test2/SIGNALduino/RDmsg.pm 74.74% <71.42%> (-4.57%) :arrow_down:
t/FHEM/00_SIGNALduino/08_DeviceData_rmsg.t 79.26% <75.00%> (-2.22%) :arrow_down:
... and 33 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

sidey79 commented 1 year ago

Bei mir steht, Du hättest 24 commits hochgeladen. Sieht so aus wie diese, welche ich zusammengefasst hatte. Kann das sein?

HomeAutoUser commented 1 year ago

Ich habe eigentlich nur deinen aktuellen Stand in GitHub desktop holen wollen und da kam die Frage… wunderte mich auch schon und verglich da alles. Es sind alle deine letzten Stände. Ich weiß nicht wieso da „MergeBranch…“ kam. Wollte dir ggf helfen und die Dateien auf ein Schema zu bringen + zusätzlich hide von mir erstellen testData Files zur Verfügung stellen.

sidey79 commented 1 year ago

@HomeAutoUser

Wenn Du nichts verändert hast, dann würde ich den Branch überschreiben und die 24 commits löschen. Mit github desktop arbeite ich nicht, aber vermutlich ist es einfacher wenn Du ihn lokal löschst und neu abholst, da ich die Historie zwischendurch aufgeräumt habe.

HomeAutoUser commented 1 year ago

@sidey79 ja mach das. Ich werde dann schauen wenn du ihn überschrieben hast.

sidey79 commented 1 year ago

@sidey79 ja mach das. Ich werde dann schauen wenn du ihn überschrieben hast.

erledigt :)

sidey79 commented 1 year ago

Beim erzeugen der Testdaten habe ich festgestellt, dass wir für 14_BresserTemeo keine Daten haben und ich bin mir auch unsicher, ob wir das überhaupt noch benötigen. So wie ich das einschätze, gegen die Daten mit W44 an SD_WS und mit P44 wird überhaupt nichts übergeben. Also vermutlich eine Modulleiche?

sidey79 commented 1 year ago

@HomeAutoUser

Die Tests sind ja nun zumindest mal durchgelaufen. Offenbar, sind aber nicht alle mir rüber gekommen, was mich wundert. Z.B. fehlt der Datensatz zu "SD_WS_50_SM".

Ich hatte das mittels Script extrahiert. Das Sortiert aber etwas anders als Du es gemacht hast. Vermutlich fehlen da noch mehr Daten.

HomeAutoUser commented 1 year ago

Offenbar, sind aber nicht alle mir rüber gekommen, was mich wundert. Z.B. fehlt der Datensatz zu "SD_WS_50_SM".

Was möchtest du davon haben? Im durchlaufenden JSON ... wenn du das noch machst, sind dsmg hinterlegt wo der dispatched getestet wird.

Wenn du nun den Datensatz 1:1 kopierst in deine "testData", so testen wir doppelt. Es muss ein Test mit der Bezeichnung " ... Opus_XT300 ..." geben.

Vermutlich fehlen da noch mehr Daten.

Was soll fehlen bzw. was denkst du, was fehlt?

Info: Deine Tests, durchlaufen das komplette JSON einmal durch, wo mehrere dmsg´s drin sind als bei deinen Tests. Wir testen so den normalen Dispatch mit den Readings. Alles andere wären Sondertests. Bitte nicht doppelt testen.

sidey79 commented 1 year ago

Ich wüsste jetzt nicht was doppelt getestet wird. Aktuell wird hier weniger als im Haupt Branch getestet und der eine Datensatz war ein Beispiel.

Soll das Tool denn die testData.json schreiben können oder nicht? Wenn ich meinen Export überarbeite, gehen deine Anpassung halt wieder weg, daher wollte ich das jetzt nicht machen.

elektron-bbs commented 1 year ago

Beim erzeugen der Testdaten habe ich festgestellt, dass wir für 14_BresserTemeo keine Daten haben und ich bin mir auch unsicher, ob wir das überhaupt noch benötigen. So wie ich das einschätze, gegen die Daten mit W44 an SD_WS und mit P44 wird überhaupt nichts übergeben. Also vermutlich eine Modulleiche?

Das sehe ich auch so. Ich habe den Code in 14_SD_WS.pm und 14_BresserTemeo mal verglichen - sieht sich verdammt ähnlich. Das war wohl eines der ersten Protokolle, die ihr in die 14_SD_WS.pm überführt habt.

HomeAutoUser commented 1 year ago

Ich wüsste jetzt nicht was doppelt getestet wird. Aktuell wird hier weniger als im Haupt Branch getestet und der eine Datensatz war ein Beispiel.

Was ist für dich ein Hauptbranch und wie ist dein komplettes Konzept angedacht.

Soll das Tool denn die testData.json schreiben können oder nicht? Wenn ich meinen Export überarbeite, gehen deine Anpassung halt wieder weg, daher wollte ich das jetzt nicht machen.

Von der Überlegung war ich abgekommen weil da zu viele Faktoren einspielen zum Vergleichen. Derzeit lasse ich auf Basis des TOOL´s und dessen SD_Device_ProtocolList.json Dateien für Tests generieren um dir Vorlagen zu bieten. Das man das besser vergleichen kann, hatte ich das Schema in den testData´s gleich gemacht.

Bleibt der Zustand https://github.com/RFD-FHEM/RFFHEM/blob/master_fix_tests_JSON/lib/Test2/SIGNALduino/RDmsg.pm#L17:L26 so? Leider kenne ich nicht den kompletten Umsetzungsgedanke nicht vollständig.

Beim erzeugen der Testdaten habe ich festgestellt, dass wir für 14_BresserTemeo keine Daten haben und ich bin mir auch unsicher, ob wir das überhaupt noch benötigen. So wie ich das einschätze, gegen die Daten mit W44 an SD_WS und mit P44 wird überhaupt nichts übergeben. Also vermutlich eine Modulleiche?

Dito.

sidey79 commented 1 year ago

Ich wüsste jetzt nicht was doppelt getestet wird. Aktuell wird hier weniger als im Haupt Branch getestet und der eine Datensatz war ein Beispiel.

Was ist für dich ein Hauptbranch und wie ist dein komplettes Konzept angedacht.

Hier nennt sich der der Hauptbranch "master". Neuerdings wird hier "main" verwendet aber es kann auch jeder andere Branchname zum Hauptbranch erstellt werden.

Soll das Tool denn die testData.json schreiben können oder nicht? Wenn ich meinen Export überarbeite, gehen deine Anpassung halt wieder weg, daher wollte ich das jetzt nicht machen.

Von der Überlegung war ich abgekommen weil da zu viele Faktoren einspielen zum Vergleichen. Derzeit lasse ich auf Basis des TOOL´s und dessen SD_Device_ProtocolList.json Dateien für Tests generieren um dir Vorlagen zu bieten. Das man das besser vergleichen kann, hatte ich das Schema in den testData´s gleich gemacht.

Bleibt der Zustand https://github.com/RFD-FHEM/RFFHEM/blob/master_fix_tests_JSON/lib/Test2/SIGNALduino/RDmsg.pm#L17:L26 so? Leider kenne ich nicht den kompletten Umsetzungsgedanke nicht vollständig.

Das war nach meinem Verständnis der Plan: Siehe https://github.com/RFD-FHEM/SIGNALduino_TOOL/issues/87#issuecomment-1345399861

Wie sieht denn eine Datei für Tests aus?

Ich fasse mal zusammen was ich verstanden habe:

SD_Device_ProtocolList.json wird nicht mehr direkt durch die Tests aufgerufen. Es ist eine Datei die von / für das TOOL ist. Jedes Modul erhält eine (ggf. auch mehrere) eigene TestData.json. TestData.json und Modulversion sind je Branch aufeinander abgestimmt (kompatibel).

Die RMSG Tests für das 00_SIGNALduino Modul basieren ebenfalls auf den TestData.json. Sofern das Modul im gleichen REPO liegt ist das einfach. Wenn das Modul ausgelagert ist z.B. RSL muss ich mir noch was überlegen. Vielleicht kann ich das in die Metadaten vom Modul hinterlegen wo die Datei zu finden ist.

Ich nehme an, Du hattest etwas anderes verstanden ;)

sidey79 commented 1 year ago

Ich hatte das mittels Script extrahiert. Das Sortiert aber etwas anders als Du es gemacht hast. Vermutlich fehlen da noch mehr Daten.

Den Fehler habe ich gefunden. Es wurde immer nur der 1. Datensatz extrahiert. Ich hole jetzt mal die anderen nach.

HomeAutoUser commented 1 year ago

Hier nennt sich der der Hauptbranch "master". Neuerdings wird hier "main" verwendet aber es kann auch jeder andere Branchname zum Hauptbranch erstellt werden.

Das habe ich richtig verstanden und denke das ist klar für alle.

Das war nach meinem Verständnis der Plan: Siehe RFD-FHEM/SIGNALduino_TOOL#87 (comment)

Wie sieht denn eine Datei für Tests aus?

Eine Vorlage sehe so aus am Beispiel SD_AS

[
   {
      "data" : [
         {
            "comment" : "self build arduino sensor with voltage output",
            "dmsg" : "P2#0880370E",
            "internals" : {
               "DEF" : "voltage_0",
               "NAME" : "ArduinoSensor_voltage_0"
            },
            "minProtocolVersion" : "1.29",
            "readings" : {
               "battery" : "2",
               "batteryState" : "ok",
               "batteryVoltage" : "3639",
               "state" : "V: 3.64",
               "trigger" : "auto",
               "voltage" : "3.64"
            },
            "revision_entry" : "2021-05-26 23:11:19",
            "revision_modul" : "14_SD_AS.pm   350 2020-10-01 20:16:11Z elektron-bbs",
            "rmsg" : "MS;P0=-503;P1=460;P3=-1024;P6=-9946;D=16101010101310101013101010101010101010131310131313101010101313131015;CP=1;SP=6;O;m2;",
            "user" : "elektron-bbs"
         },
         {
            "comment" : "self build arduino sensor with temp output",
            "dmsg" : "P2#0680E580",
            "internals" : {
               "DEF" : "temp_0",
               "NAME" : "ArduinoSensor_temp_0"
            },
            "minProtocolVersion" : "1.29",
            "readings" : {
               "battery" : "ok",
               "batteryState" : "ok",
               "state" : "T: 22.9",
               "temperature" : "22.9",
               "trigger" : "auto"
            },
            "revision_entry" : "2021-05-26 23:00:22",
            "revision_modul" : "14_SD_AS.pm   350 2020-10-01 20:16:11Z elektron-bbs",
            "rmsg" : "MS;P1=484;P2=-474;P4=-990;P6=-9960;D=16121212121214141214121212121212121414141212141214141212121212121215;CP=1;SP=6;O;m2;",
            "user" : "elektron-bbs"
         },
         {
            "comment" : "self build arduino sensor with raw output",
            "dmsg" : "P2#0AC30E01",
            "internals" : {
               "DEF" : "raw_3",
               "NAME" : "ArduinoSensor_raw_3"
            },
            "minProtocolVersion" : "1.29",
            "readings" : {
               "battery" : "3",
               "batteryState" : "ok",
               "raw" : "270",
               "state" : "S: 270",
               "trigger" : "auto"
            },
            "revision_entry" : "2021-05-26 23:01:27",
            "revision_modul" : "14_SD_AS.pm   350 2020-10-01 20:16:11Z elektron-bbs",
            "rmsg" : "MS;P2=-9999;P3=504;P4=-511;P5=-965;D=32323434343435343534353534343434353534343434353535343434343434343435;CP=3;SP=2;m2;",
            "user" : "elektron-bbs"
         },
         {
            "comment" : "self build arduino sensor with humidity output",
            "dmsg" : "P2#09803A82",
            "internals" : {
               "DEF" : "humidity_0",
               "NAME" : "ArduinoSensor_humidity_0"
            },
            "minProtocolVersion" : "1.29",
            "readings" : {
               "battery" : "ok",
               "batteryState" : "ok",
               "humidity" : "57",
               "state" : "H: 57",
               "trigger" : "auto"
            },
            "revision_entry" : "2021-05-26 23:03:54",
            "revision_modul" : "14_SD_AS.pm   350 2020-10-01 20:16:11Z elektron-bbs",
            "rmsg" : "MS;P0=-9561;P1=458;P2=-527;P4=-982;D=10121212121412121414121212121212121212141414121412141212121212141215;CP=1;SP=0;m2;",
            "user" : "elektron-bbs"
         }
      ],
      "id" : "2",
      "module" : "SD_AS",
      "name" : "ArduinoSensor"
   }
]

Ich nehme an, Du hattest etwas anderes verstanden ;)

Ja zum Teil.

Ich überlege, wie wir auf einen Nenner finden ohne uns im Kreise zu drehen.

Jedes Modul erhält eine (ggf. auch mehrere) eigene TestData.json. TestData.json und Modulversion sind je Branch aufeinander abgestimmt (kompatibel).

Erkenntnis für mich ist soeben die Aussage, das im Masterbranch (Hauptbranch) nicht mehr das komplette JSON durchlaufen wird für tests. Da der RMSG Tests auf Basis vom Modulname und den hinterlegten Daten aus der testData.json verarbeitet wird.

Meine ersten Gedanken:

Das zerstört den Gedanke von damals, das sämtliche Devices, welche mit dem SIGNALduino verarbeitet werden, gesammelt werden in dem JSON vom TOOL. Es gäbe 2 Varianten

Ungern möchte uns im Kreise drehen lassen, da es genügend andere offenen Baustellen gibt.

PS: Gern belasse es so wie dein jetziger Ansatz ist und wir führen es "doppelt" und du solltest du mit dem Ergebnis der Tests unzufrieden sein, musst du Daten ergänzen. PS2: vorerst G8 erstmal :-)

sidey79 commented 1 year ago

Hmm, ich Stelle mir das so vor, dass das TOOL die Daten einfach aus einer anderen Quelle lädt und wir diese über die Metadaten bekannt machen.

Dadurch wäre doch alles vereinfacht.

HomeAutoUser commented 1 year ago

Hmm, ich Stelle mir das so vor, dass das TOOL die Daten einfach aus einer anderen Quelle lädt und wir diese über die Metadaten bekannt machen.

Dadurch wäre doch alles vereinfacht.

Alle Daten im TOOL werden manuell eingepflegt beim entwickeln. Diese kannst du nicht irgendwo auslesen. ;)

sidey79 commented 1 year ago

Alle Daten im TOOL werden manuell eingepflegt beim entwickeln. Diese kannst du nicht irgendwo auslesen. ;)

Hmm, das ist eine Frage von an welcher Stelle werden sie eingepflegt. Vielleicht macht es keinen Unterschied, ob sie in dem einen oder anderen Repo hinterlegt werden. Hauptsache ist doch, dass alle Tools an die Daten kommen.

HomeAutoUser commented 1 year ago

Hmm, das ist eine Frage von an welcher Stelle werden sie eingepflegt. Vielleicht macht es keinen Unterschied, ob sie in dem einen oder anderen Repo hinterlegt werden. Hauptsache ist doch, dass alle Tools an die Daten kommen.

Als erstes werden die Daten bisher immer im JSON eingepflegt, da es dort einen einfachen "Push via BUTTON" gibt. Wenn du auf die Erweiterung der Tests dann bestehst bzw. um den Code abzusichern, dann würde es mit Copy und Paste zu dir in die testData kommen.

Von welchem Repro diese kommen oder abgerufen werden, ist sicherlich egal.

Ich tendiere gerade dazu, es so wie jetzt beizubehalten und wir führen die Daten so doppelt bzw. erst beim Wunsch von Daten im Test werden wir diese wie oben genannt via C&P in die Files eintragen. Unabhängig habe ich vielleicht eine Idee, meine "Push via BUTTON Methode" ggf. zu überarbeiten, das ich mir die dazugehörige Testdatei herunter lade und erweitere.

PS: Wieso schlagen die Tests hier ab und zu fehl? Diese waren doch schonmal "grün" ?

PS2: Nur eine spontane Idee, ist es ein großer Aufwand die Testfiles von dir automatisch zu füllen mit einem Script welche die Daten aus dem JSON holt? ... ODER ist es einfacher wenn man dies via Schleife durchläuft und ggf. "Extra Spezialfälle" in eine weitere Datei testData sepaarat schreibt? <--- nur ein Gedankenspiel

sidey79 commented 1 year ago

Ich tendiere gerade dazu, es so wie jetzt beizubehalten und wir führen die Daten so doppelt bzw. erst beim Wunsch von Daten im Test werden wir diese wie oben genannt via C&P in die Files eintragen. Unabhängig habe ich vielleicht eine Idee, meine "Push via BUTTON Methode" ggf. zu überarbeiten, das ich mir die dazugehörige Testdatei herunter lade und erweitere.

So in der Art hatte ich das gemeint. Die doppelte Pflege braucht es dann aber vermutlich nicht mehr.

PS: Wieso schlagen die Tests hier ab und zu fehl? Diese waren doch schonmal "grün" ?

Weil jetzt ordentlich getestet wird und nicht bei Abweichungen der Fehler unterdrückt wird ;) Die letzte offen Abweichung war noch eine "alte" Schuld. Die Werte für dispatch_repeats haben bei einigen Einträgen nicht gestimmt. Ich habe das angepasst, sollten jetzt fehlerfrei durchlaufen. *bingespannt*

PS2: Nur eine spontane Idee, ist es ein großer Aufwand die Testfiles von dir automatisch zu füllen mit einem Script welche die Daten aus dem JSON holt? ... ODER ist es einfacher wenn man dies via Schleife durchläuft und ggf. "Extra Spezialfälle" in eine weitere Datei testData sepaarat schreibt? <--- nur ein Gedankenspiel

Das Schema ist in beiden Fällen identisch, daher ist es kein Problem es zu schreiben. So habe ich die Daten letztlich auch rüber geholt: Ich bin aber immer noch überzeugt, dass SD_Device_ProtocolList.json nicht nötig ist, wenn direkt mit den testData.json gearbeitet werden könnte :)

So habe ich die Daten überführt:

#!/bin/perl
use Data::Dumper;
use JSON; 

my $testDataArray=undef;

sub loadJson {
    my $url = shift;

    my $json_text;
    if ($url =~ /^https:\/\//i)
    {
        use HTTP::Tiny;
        my $response = HTTP::Tiny->new->get($url);
        die("Failed!\n") unless $response->{success};
        $json_text = $response->{content};
    }  else {
        $json_text = do {
        open(my $json_fh, "<:encoding(UTF-8)", $url)
            or die(qq[Can't open $url: $!\n]);
        local $/;
        <$json_fh>
        };
    }

    $testDataArray = eval { decode_json($json_text) };
    if($@){
        die("open json file SD_Device_ProtocolList was not possible $?"); 

    }
}

sub filterTestDataArray {
  my $modulename = shift;

  $modulename =~ s/^[0-9][0-9]_//; # Remove leading digtis
  my @results;
  return  if (ref $testDataArray ne 'ARRAY');
  while ( (my $pID, my $testSet) = each  (@{$testDataArray}) )
  {
      if (defined $testSet->{module} && $testSet->{module} eq $modulename)
      {
          push @results, $testSet
      }
  }

  return @results;
}

loadJson('https://raw.githubusercontent.com/RFD-FHEM/SIGNALduino_TOOL/master/FHEM/lib/SD_Device_ProtocolList.json');

my $json = JSON->new;
$json = $json->pretty([$enable]);
my @tData = filterTestDataArray($ARGV[0]);

use Data::Dumper;
#exit 0;

for my $p (0 .. $#tData )
{
    for my $i (0 .. scalar @{$tData[$p]{data}}-1 )
    {
        if ( !exists $tData[$p]{data}[$i]{tests} ) {
            $tData[$p]{data}[$i]{tests}[0] = ({ "comment" => "#$i"});
        }
        for my $element (qw /attributes setreading returns/)
        { 
            if ( exists $tData[$p]{data}[$i]{$element} ) {
                $tData[$p]{data}[$i]{tests}[0]{$element} = $tData[$p]{data}[$i]{$element};
                delete ($tData[$p]{data}[$i]{$element});
            }
        }

    }
}

#my @result =  @tData ;

my $json_text = $json->utf8->encode( \@tData );
#print $ARGV[0];
#print "\n";
print $json_text;
HomeAutoUser commented 1 year ago

Ich bin aber immer noch überzeugt, dass SD_Device_ProtocolList.json nicht nötig ist, wenn direkt mit den testData.json gearbeitet werden könnte :)

Das mag sein, WENN man nur die Daten deiner Module mit dem TOOL verarbeiten würde. Da aber auch darin Daten von Fremdmodulen sind, welche du nicht testest, so negiere ich deine Aussage :-P

Ich war mal so frei und habe eine leichte Warning gefixt grins. So minimiert man die Ausgaben im gesamt RAW Log hihi.

sidey79 commented 1 year ago

Ich bin aber immer noch überzeugt, dass SD_Device_ProtocolList.json nicht nötig ist, wenn direkt mit den testData.json gearbeitet werden könnte :)

Das mag sein, WENN man nur die Daten deiner Module mit dem TOOL verarbeiten würde. Da aber auch darin Daten von Fremdmodulen sind, welche du nicht testest, so negiere ich deine Aussage :-P

Ja da ist was dran. An die "anderen" Module habe ich nur kurz gedacht, aber auch da könne das Tool in einen Ordner t/FHEM//testData.json schreiben, nur das auffinden kann dann nicht über die Metadaten erfolgen, das geht dann nur über eine Suche im Dateisystem. (Für beides ist der code hinterlegt)

Ich war mal so frei und habe eine leichte Warning gefixt grins. So minimiert man die Ausgaben im gesamt RAW Log hihi.

Da gibt es noch einige aber jetzt wollte ich erst mal diesen Teil fertig abschließen.

sidey79 commented 1 year ago

@HomeAutoUser

Ich würde es bei diesem Stand zunächst einmal belassen wollen.

HomeAutoUser commented 1 year ago

@HomeAutoUser

Ich würde es bei diesem Stand zunächst einmal belassen wollen.

Geht in Ordnung.

elektron-bbs commented 1 year ago

Mich würde interessieren, wann und wohin dann welche Testdaten sollen.

  1. Sehe ich das richtig, das für die Test bei Github die Daten aus dem SIGNALduino-Tool nicht mehr verwendet werden?
  2. Wenn Testdaten bei den Modulen sind, werden mir Fehler dann schon bei Änderungen im neuen Branch angezeigt oder auch wieder erst beim Pull-Request?
sidey79 commented 1 year ago

@elektron-bbs

Daten aus dem Signalduino Tool werden aktuell keine mehr direkt verwendet.

Verwendet wird vorzugsweise was lokal im Repository liegt. Wenn es dort keine gibt, werden auch welche verwendet, welche in den Meta Daten verlinkt wurden. Das trifft aber auf die hier im Repo hinterlegten nicht zu, da diese lokal hinterlegt wurden.

Die Tests werden auch bei einem push in einen neuen Branch ausgeführt. Die Anzeigemöglichkeiten beschränken sich dann allerdings auf das Log.

elektron-bbs commented 1 year ago

Die Tests werden auch bei einem push in einen neuen Branch ausgeführt. Die Anzeigemöglichkeiten beschränken sich dann allerdings auf das Log.

Man wird aber hoffentlich darauf hingewiesen, das Fehler aufgetreten sind?

sidey79 commented 1 year ago

Die Tests werden auch bei einem push in einen neuen Branch ausgeführt. Die Anzeigemöglichkeiten beschränken sich dann allerdings auf das Log.

Man wird aber hoffentlich darauf hingewiesen, das Fehler aufgetreten sind?

Ja der Fehlerbericht kommt per E-Mail. War aber auch vor diesem PR schon so.