github.com/wolfi-dev/wolfictl@v0.16.11/pkg/dag/testdata/cycle/README.md (about)

     1  # Cycle
     2  
     3  Test fixtures to support resolving cycles.
     4  
     5  Details are in [graph_test.go](../../graph_test.go), specifically the case named "resolve cycle".
     6  
     7  What we want is to set up a case so that we have a chain of dependencies set up, and then try to reverse
     8  them. This, in turn, should lead to unwinding all of the end dependencies, doing the reverse dependency,
     9  and then redoing the unwound dependencies, finding a lower one from elsewhere.
    10  
    11  The structure is something like this. We have two repositories:
    12  
    13  * "local", which represents yaml files in this directory
    14  * "upstream", which is files in `packages/`
    15  
    16  Some of the packages in "local" also are in "upstream", but at lower versions; others
    17  are not.
    18  
    19  The goal of the test is to ensure that cycles can be resolved properly. The initial dependencies
    20  are resolved locally. The final package resolved depends on something that is
    21  available only locally, yet creates several paths to cycles.
    22  This should cause some of the existing dependencies to unwind, resolve the one that would cause a cycle, and then return the ones that we unwound, which now should resolve to upstream.
    23  
    24  Package naming is intentional, to ensure sort order.
    25  
    26  Local packages are:
    27  
    28  * a:1.3.5 ; depends on b, c, d
    29  * b:1.2.3 ; depends on c, d
    30  * c:1.5.5 ; depends on d
    31  * d:2.0.0 ; depends on a
    32  
    33  Upstream packages are:
    34  
    35  * b:1.0.0
    36  * c:1.0.0
    37  * d:1.0.0
    38  
    39  The flow we create is as follows.
    40  
    41  1. Resolve a: this should show it depending on:
    42     * b:1.2.3@local
    43     * c:1.5.5@local
    44     * d:2.0.0@local
    45  2. Resolve b: this should show it depending on:
    46     * c:1.5.5@local
    47     * d:2.0.0@local
    48  3. Resolve c: this should show it depending on:
    49     * d:2.0.0@local
    50  4. Resolve d: this depends on a, so it should create the cycle.
    51  
    52  Resolving the cycle should unwind:
    53  
    54  * a -> d:2.0.0@local
    55  * b -> d:2.0.0@local
    56  * c -> d:2.0.0@local
    57  
    58  Then d -> a should resolve:
    59  
    60  * d -> a:1.3.5@local
    61  
    62  Finally, it should return the unwound dependencies, with their new dependencies:
    63  
    64  * a -> d:1.0.0@upstream
    65  * b -> d:1.0.0@upstream
    66  * c -> d:1.0.0@upstream
    67  
    68  ## Generating the package directory
    69  
    70  The contents of the "upstream" need only be as follows:
    71  
    72  * `cycle/packages/key.rsa.pub` - the public key
    73  * `cycle/packages/x86_64/APKINDEX.tar.gz` - the package index
    74  
    75  We do not need the actual apk files, as they are not used in this test.
    76  
    77  To do this:
    78  
    79  1. Generate the key
    80  1. Create the `APKINDEX.tar.gz` from [APKINDEX](./APKINDEX)
    81  1. Sign the index
    82  
    83  From within the `pkg/dag/` directory:
    84  
    85  ```shell
    86  $ mkdir -p testdata/cycle/packages
    87  $ mkdir -p testdata/cycle/packages/x86_64
    88  $ melange keygen testdata/cycle/packages/key.rsa
    89  $ tar -C testdata/cycle -czf testdata/cycle/packages/x86_64/APKINDEX.tar.gz APKINDEX
    90  $ melange sign-index --signing-key testdata/cycle/packages/key.rsa testdata/cycle/packages/x86_64/APKINDEX.tar.gz
    91  ```
    92  
    93  ## About APKINDEX
    94  
    95  Be _very careful_ if you edit [APKINDEX](./APKINDEX). Some editors like to "clean it up" and remove
    96  trailing newlines. That will break how apk reads the file and miss some packages.