Adds a Tuf local store abstraction and a file based implementation

[patflynn]

TUF local repo store sets us up to be able to use an in-memory implementation for read-only file system scenarios.

Progress towards #60

Signed-off-by: Patrick Flynn [email protected]

[vlsi]

@patflynn , what do you think of putting "abstractions" into sigstore-testkit folder?

They might be useful across more than a single module, and I'm inlined it might be slightly better if src/test includes code with @Test methods "only".

[patflynn]

@vlsi You're suggesting putting the TestResources into testkit? I like the idea. This was the rule at Google too. It's a bit tricky in this case because I would have to move the associated resource data, which I like a little less from a navigatability standpoint for test maintainers.

[vlsi]

It's a bit tricky in this case because I would have to move the associated resource data

That is right, however, reading files from src/... might be not the best idea.

WDYT of using Class.getResource(...)?
Then TestResources could take Class<> argument, and it could use that to lookup the resources.
An alternative option is to use com.google.common.io.Resources#getResource(java.lang.Class<?>, java.lang.String)

[patflynn]

Yeah that makes sense. I was avoiding it initially because the API itself doesn't read resources from the class path as the local repo and trusted root can be anywhere on the filesystem, but I should be able to bridge that.

[patflynn]

This does get a little nasty though as circular deps are going to rare their ugly heads :). These test support classes will be quite limited since they won't be able to use any sigstore-java types unless we break the tests out into a separate module..

[vlsi]

These test support classes will be quite limited since they won't be able to use any sigstore-java types

I do not follow you here. sigstore-testkit dependency on sigstore-java is just fine.

[patflynn]

Aha! You're right. That's great! I guess Gradle doesn't include the test deps when testing module cycles. GTK.

[vlsi]

I guess Gradle doesn't include the test deps when testing module cycles. GTK.

Depending on "test" artifacts is weird, and Gradle does not provide out-of-the-box to "depend on files from src/test/..."

Here's a sample where calcite-testkit depends on calcite-core: https://github.com/apache/calcite/blob/e41555f568510df04d3883516b2195393a93426d/testkit/build.gradle.kts#L22, and it works great.

[patflynn]

@vlsi PTAL

[patflynn]

Do you mean move the TestResources class to testkit as TufTestResources or something like that?

…

On Wed, Sep 14, 2022 at 9:20 AM Vladimir Sitnikov ***@***.***> wrote: @patflynn <https://github.com/patflynn> , what do you think of putting "abstractions" into sigstore-testkit folder? They might be useful across more than a single module, and I'm inlined it might be slightly better if test/src includes code with @test methods "only". — Reply to this email directly, view it on GitHub <#149 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB37SHPNAYOXMSR3QQ2TRILV6HGJLANCNFSM6AAAAAAQMMLLYI> . You are receiving this because you were mentioned.Message ID: ***@***.***>