QA/Bibisect/da

    From The Document Foundation Wiki
    < QA
    This page is a translated version of the page QA/Bibisect and the translation is 28% complete.
    Outdated translations are marked like this.

    Introduktion

    Bibisect står for ”binær bisektion“ Det er en procedure, der hjælper med at identificere tilsagn, der har forårsaget regressioner. Regressioner er den mest irriterende menneskelige efterladenskab, som uheldigvis dukker op med softwareudvikling og QA (kvalitetssikring). Vi vil behandle regressioner hurtigt og før tiden er gået og de bliver sværere og sværere at vurdere og ordne.

    Hvordan fungerer Bibisection?

    Hver Bibisect-pakke er et git-lager befolket med hundreder eller tusinder prototyper af LibreOffice. Tilføjet til lageret in kronologisk orden giver prototyperne en hurtig og enkel måde for os at teste en fejl mod imod mange forskellige versioner uden at skulle kompilere LibreOffice hver gang, vi skifter til en anden version.

    Vi kan geare værktøjerne, der er indbygget i git til binære søgninger gennem tilsagnene (”fx git bisect“) såvel som drage fordel af kompressionen og de-duplikeringsfunktioner, der inkluderet i git. Fx i en serie af prototyper, som hver kunne optage 500 MB diskplads, skal vi gennem de-duplikation potentielt kun bruge kun 25 MB til hver ekstra prototype.

    Watch Effective Bisection and Bibisection (Matthew Francis's talk at LibOCon 2015 on YouTube) for both an introduction, and practical details.

    Detaljer

    En succesfuld bibisection vil overlade udviklerne kun nogle få tilsagn at gennemsøge for at finde det 'skyldige' tilsagn, som vi tror indførte en regression. Afhængigt af det bestemte bibisect-lager, kan samlingen være på 60, 100 eller bare 2 tilsagn. (Vi har også nogle meget 'grove' bibisect-lagre, som bruger frigivne versioner + beta + RC-prototyper, og disse har måske samlinger der spænder over flere hundreder tilsagn)

    QA kan tage det ekstra skridt, der består i en fuldstændig bibisection (der bestemmer det nøjagtige tilsagn) eller kan overlade det til udviklerne. Det er ofte let at at finde det tilsagn, som har forårsaget problemet, efter at fejlen er blevet bibisectet. Med omkring 10 GB vil du have hundreder af prototyper at arbejde med. En bibisect kan tage så lidt som 15 minutter.

    Aktuelt kan bibisect udføres på:

    As can be seen from the Commits in range and Number of builds, depending upon the particular bibisect repository, this range might be on average 80 commits for old "43max" repository (reaching hundreds of source commits in some builds) to just 1 or 2 commits for newer repositories. (We also have some very 'coarse' bibisect repositories that use released versions + beta + RC builds, and these may have ranges spanning multiple hundreds of commits).

    If build commit or range is found, bug is marked with keyword "bibisected", and if source commit is found, bug is additionally marked "bisected".

    Generelle Instruktioner

    It might be a good idea for beginners to start by tracing the steps of a bibisect that was already completed successfully. For this purpose we have a bibisecting tutorial.

    Bemærk: Hver operativsystem er særligt, læs venligst venligst de fulde instruktioner, som vedrører dit specifikke operativsystem (GNU/Linux, macOS eller Windows) for mere komplette instruktioner, instruktionsvideoer og anden beslægtet information.

    Bibisection hviler på 6 trin:

    1. Opsætning af dit miljø, herunder installation af eventuel ekstra software
    2. Download af bibisect-pakken
    3. Bibisection af fejlen
    4. Fremstilling af en bibisect-log
    5. Tilknytning af bibisect-loggen til fejlrapporten
    6. Opdatering af fejlrapportfelterne

    Once set up, for each bug:

    1. Bibisect the bug
    2. Comment in the bug report with the results
    3. Replace the keyword 'bibisectRequest' with 'bibisected'
    4. If the precise commit causing the regression has been identified, also add the keyword 'bisected', add the developer as CC, and comment 'Adding Cc: to <developer's name>'

    Note that you should only add the original author to the CC ("author" on git.libreoffice.org, or "owner" on gerrit), not any reviewers. If a developer has retired from the project (check the date of their last commits), there is no point in adding anyone to the CC. Rather in this case, you should bump the priority of the bug report.

    Commit ranges

    Some bibisect repositories have ranges of source commits folded into a single chunk. If after completing a bibisect you are presented with only a single one of these chunk commits, you can get the range by first copying the hash (note: not the source hash) and using it in a git log command like so:

    git log c3f9dc54188b316a61dd871b63734d49b05f5d7f

    Now you can copy the source hashes of the first and previous displayed commits and separate them with .. to construct a range query like so:

    https://git.libreoffice.org/core/log/7c4d3ea6ba4d42b4dda5148a00c8c411b5d7703d..5b195fbcf7a441aeb193f6abd08b877e580938e0
    

    This will allow you to skim commit messages looking for related subjects. For deeper scrutiny, see the section on detective work.

    Finding the earliest version affected

    If you have a local copy of the core repository, you can update the Version field in the bug report thanks to some git commands:

    1. First, make sure you have all the tags:

    git fetch --tag

    2. Then, use `name-rev` to find the context (more precisely, by how many revisions it preceded the earliest tag that contains the commit):

    git name-rev <commit>

    3. If that didn't give a useful tag that matches a LibreOffice version, you can list all tags that contain the commit and have "libreoffice" in the name with:

    git tag --contains <commit> | grep libreoffice

    Begrænsninger

    Udførelse af en 'bibisect' er kun muligt, hvis vi har et tilgængeligt lager til det korrekte operativsystem, der dækker den korrekte samling af LibreOffice-tilsagn. Vi har meget god dækning af GNU/Linux og forbedrer vores dækning af Windowa og macOS.

    Nogle regressioner er vanskelige at genskabe og kræver måske flere testkørsler, før fejlen viser sig. Som du måske kan forestille dig, er det ”meget“ svært at bibisecte sådanne regressioner, og kræver at du foretager mange testkørsler efter hver udgivelse af en ny version af LibreOffice for at give nogen sikkerhed / statistik for, at fejlen faktisk findes eller ikke findes i den givne version.

    Vi har aktuelt ikke bibisect-understøttelse af

    Versioner

    Versioner er oplistet på hver OS-side. Se #Detaljer ovenfor.

    Ikke Bibisectable

    Nogle fejl er ikke bibisect-bare. De omfatter

    • Fejl, der ikke viser sig på en understøttet platform (se #Begrænsninger)
    • Fejl, der er ældre en vores bibisect-prototyper ”(Vi arbejder på at udvide dækningsområdet)“
    • Fejl, der er afhængige af prototypeindstillinger, der ikke er aktiveret i TDF-prototyper ”(fx ”'-kde“')“

    Hvis du finder, at en fejl med nøgleordet bibisectRequest ikke er bibisectbar, skriv en kommentar om, hvorfor vi ikke kan bruge bibisect til at opspore begyndelsen af dette problem, og erstat nøgleordet bibisectRequest med notBibisectable.

    Fejlfinding

    Find fejl, der behøver bibisect

    Finding bugs needing bibisect

    The following bugs with keyword bibisectRequest are waiting for a bibisect:

    In addition all unresolved regressions in LibreOffice might benefit from bibisecting.

    Find fejl, der allerede er bibisectet

    Se venligst links til bugzilla-forespørgsler i here.

    Når informationen ovenfor er tilføjet fejlen, ved en udvikler , at regressionen blev introduceret mellem tilsagnene fb754a0df859e30255c25af8fa19bfaa75f257e7 (good) og 2d19e9bb07ccff3134f855812dddfda5c07b1fe4 (bad) på master. A:

    git log fb754a0df859e30255c25af8fa19bfaa75f257e7..2d19e9bb07ccff3134f855812dddfda5c07b1fe4

    på kildelageret, der vil så vise de 128 tilsagn, herunder den, som introducerede fejlen og gøre det meget lettere for udvikleren at nærme sig den skyldige. Se flere detaljer i:

    Specielle situationer

    Bibisecting language-specific bugs

    The TDF bibisect repositories provided do not include any lang-packs.

    To bibisect bugs which work good with english UI, but bad with non-english UI (like CJKs): one should copy-paste the following files, from a release build which has your language, to the same location of the bibisect repo:

    1. program/resource/<your_lang_tag>
    2. share/registry/Langpack-<your_lang_tag>.xcd
    3. share/registry/res/fcfg_langpack_<your_lang_tag>.xcd
    4. share/registry/res/registry_<your_lang_tag>.xcd

    The suggested language resources you should copy is the one for the same major branch. For example, for the bibisect-linux-64-6.0 repo, you can copy from 6.0.1.1 release.

    Kørsel med en separat brugerprofil

    For at oprette en mappe til separate profiler på /tmp/ (som vil blive fjernet automatisk under den næste maskinopstart):

    ./opt/program/soffice -env:UserInstallation=file:///tmp/soffice-bisect

    Hvis du vil begynde forfra på hver bisect-gentagelse, kan du tilføje nummeret på git-tilsagnet til mappens navn. For eksempel

    ./opt/program/soffice \
    -env:UserInstallation=file:///tmp/soffice-bisect-$(git rev-parse HEAD)

    Find en løsning

    Sommetider er en fejl indirekte skade af en anden (måske mindre) fejl på en uklar måde. I sådanne tilfælde er en anden fejl måske blev fikset på masteren, men ikke tilbageporteret til udgivelsesforgreningen. Du kan finde løsningen (fix'et), ligesom du finder en fejl, bortset fra at du skal skrive

    git bisect good
    i stedet for
    git bisect bad
    og omvendt. Hvis løsningen er lille og vigtig nok, kan den sandsynligvis let blive tilbageporteret til udgivelsesforgreningen.

    Sometimes a bug is a collateral damage of another (possibly minor) bug, in a non obvious way. In such cases that other bug might be fixed on master, but was not backported to the release branch. To identify a problem-fixing commit you can use:

    git bisect start --term-new=fixed --term-old=unfixed
    git bisect fixed master
    git bisect unfixed <some-old-sha> # you can use "git log --reverse" to detect the first revision in the bibisected package

    As you test, say

    git bisect fixed
    or
    git bisect unfixed
    as appropriate.

    If the fix is small and important enough, it likely can be easily backported to the release branch.

    Checking out a specific commit based on source hash

    Sometimes you already know a specific source commit has/does not have the bug you are hunting.

    Copy the source hash from the LibreOffice git history and use it to grep in the bibisect repo log like so:

    git log --all --grep='29a9f433c268414747d8ec7343fc2b5987971738'

    Copy the commit hash of the bibisect repo and do a checkout for it to verify your assumption:

    git checkout 38758b70f5278d4d8292a2e857e80a9a1130f38e

    You can use the repo commit hash when determining the bad-good range to bisect:

    git bisect start 38758b70f5278d4d8292a2e857e80a9a1130f38e oldest

    Doing detective work inside a commit range

    In case your bibisect result is a range of commits and you have trouble locating the offending commit, you might make your life easier by searching with a keyword.

    An example for a case, where we know the problem is in Calc's Navigator view:

    git log --stat --pretty=short --graph 169bd7718264b0e312052757f9bbd2321e1399c2...ff8b873936aa72b17309da4bfc2775573a5b1f55 | grep -B 10 -A 10 --color=always "sc/source/ui/navipi" | less -R

    Adjust the -B and -A grep parameters to control how many lines before and after the hit you want to display. When piping to less, -R preserves the colouring of search results.

    Bisect skip hell

    Sometimes we get stuck in a miserable situation, where we have to use git bisect skip over and over again due to various reasons. There are ways of getting out of these infuriating messes and here we will show one of them.

    Example bug: tdf#123095

    Bug appeared in 4.0-4.1 range.

    There are lots of commits, where the autofilter is not shown at all, so have to skip those.

    We can use git bisect visualize to show us the remaining suspected commits:

    git bisect visualize --oneline > /some/path/bisect-viz-123095.txt

    The earliest bad results are at the top while the ones you have skipped are at the bottom. The commit below the bottom is the last known good one.

    The top results included

      b842ac1 source-hash-7b4d76772ef76a8de852ed647ed0cad368f70189
      40ef04e source-hash-dc173b7f2a550185404aacbc6da744cb6d1880fc
      8e697de source-hash-eb96e4325278f31b9e6fbc1d5c6a01543204ded6
    

    Doing git checkout b842ac1, test, continue with the next etc. it turns out the third one from the top was already a skippable commit.

    A range query with the source hashes in the style bottomcommit..firstbadcommit can be made.

    Searching for "filter" in the displayed results leads to a suspicious commit about sorting autofilter popup items.

    If soffice is failing with a non-zero exit code - this probably means a crash - a solution under QA/Bibisect/Automation#Tidbits for efficiency offers a script to ease the pain of repeatedly skipping failed probes.

    Finding source commits from bibisect

    If bibisect was done, but not likely to be correct or in a repository known to have large range of source commits, we can check the range by finding a previous build commit from the found one and then find the source range.

    $ git log -1 1f14665c5624bc7a502738aa8f4f2bd70a211e72^
    $ git log --oneline b6c016da23d309b4ac7d154bc33a22397974ed73..d85fd8a85501547d5bb87822d2589a07aed7f2d6

    Problemløsning

    Beskriv venligst dine problemer og hvordan du løste dem. Dette afsnit dækker spørgsmål, som dækker mere end et OS. Om OS-specifikke spørgsmål se venligst de individuelle OS wikisider.

    Umuligt at udtrække filer

    Hvis du ikke kan udtrække filer (du skulle få en fejlmeddelelse). Prøv at omdøbe filen fra *.tar.lzma til *.tar.xz.

    Installeret LibreOffice blev uventet ændret

    Problemer / Beskeder:

    Problem / Messages:

       error: Your local changes to the following files would be overwritten by checkout:
         opt/program/pythonloader.pyc
         opt/program/uno.pyc
         opt/program/unohelper.pyc
       Please, commit your changes or stash them before you can switch branches.
       Aborting
    

    'Løsninger'::

    git checkout .

    vil reparere problemet. Derefter kan du starte den næste testkørsel som sædvanligt med

    git bisect good # or git bisect bad

    Hvis det ikke løser problemet, kan du prøve

    git clean -fd
    git reset --hard

    Den ultimative reparation er at slette alt undtagen en skjult

    git checkout oldest

    Umuligt at start soffice

    Problem: Efter forsøg på at køre soffice inde i bibisect får du fejlmeldingen "unexpected operator terminate called after throwing an instance of 'com::sun::star::uno::DeploymentException'“

    Problem 1: Upon trying to run soffice within bibisect you receive the error "unexpected operator terminate called after throwing an instance of 'com::sun::star::uno::DeploymentException'

    Løsning: Nulstil din LibreOffice-profil, der er placeret i ~/.config/libreoffice. Sørg for at tage sikkerhedskopi af mappen, hvis du har nogen som helst indstillinger, du vil bevare til brug med din stabile LibreOffice-udgave. Når du er færdig med bibisect kan du prøve at genskabe din sikkerhedskopi på dens oprindelige plads (dvs. slette den den nye profilmappe og erstatte den med den sikkerhedskopierede).