proxying support for team development

[Eugene Yokota]

Hi,

Whether the metadata, auth, and file are centralized or de-centralized,

it'd be nice to let one instance of adept act as the metadata/auth/file server for the others (like git).

This allows locking down network access in firewalled environment,

or locking down SNAPSHOT to a specific artifact in a single location.

-eugene

[Mark Harrah]

At the most basic, you'd have a tool that merges and splits repositories. Implementing it is straightforward for file repositories based on hash and then you wouldn't need any special server software. An on-demand proxy might be desirable in places that don't actively fetch the desired dependencies. I think that is also straightforward since there is a 1:1 mapping between a path and the content.

For git repositories, it is mostly straightforward to merge/split. If you want things to stay signed, the merge tool has to verify the commits being merged are signed and then sign the merge commit. If a human does the merge, they can sign it. Automated signing by a machine is a bit more complicated I think.

If there are conflicts, you probably want a human to resolve them or perhaps just let the first repository win. I don't think this needs a proxy, since an environment is likely to centrally control updating the metadata, right?

I think you can lock down without this, though. When you lock down, store the repository URI + commit for each repository. That should be enough, right?

-Mark

> -eugene
>

[Eugene Yokota]

On Friday, February 22, 2013 6:22:49 PM UTC-5, Mark Harrah wrote:

On Fri, 22 Feb 2013 09:13:50 -0800 (PST)

For git repositories, it is mostly straightforward to merge/split.  If you want things to stay signed, the merge tool has to verify the commits being merged are signed and then sign the merge commit.  If a human does the merge, they can sign it.  Automated signing by a machine is a bit more complicated I think.

If there are conflicts, you probably want a human to resolve them or perhaps just let the first repository win.  I don't think this needs a proxy, since an environment is likely to centrally control updating the metadata, right?

I want to continue on these points on the "inter-repo deps"

 

I think you can lock down without this, though.  When you lock down, store the repository URI + commit for each repository.  That should be enough, right? 

There are two lockdowns that I mentioned.

1. network lockdown.

2. revision lockdown.

For revision lockdown, I was thinking of dynamic revisions like (-SNAPSHOT)

beging able to go back in time (git branch maybe?) and getting the latest at some point in the past.

You're right that it could be achieved using hash number similar to source deps today,

but could potentially be non-DRY without some company wide sbt plugin.

In any case it's a secondary point.

My main concern is network-wise lockdown as a potential requirement.

This means that if we do use PGP or some other way of verifying authenticity, 

it needs to be done either at the server at the point of accepting a metadata,

but individual node cannot go out to get the PGP keys etc.

So either relaying trust, or proxying auth info.

-eugene