Hi Ken,
I haven't set up git LFS but the attached diagram shows how I'd expect to set
it up, following the pattern we use for Ivy and Maven repos.
Each site has
* some local repo(s);
* an "foo-outgoing" virtual repo which includes only the local repo(s);
* an "other-site-foo" remote repo for each other site, which points to
the other "-outgoing" repos;
* a "foo" virtual repo which includes "foo-outgoing" (i.e., all the
relevant local repos from "this" site) and all "other-site-foo" repos (i.e.,
just the relevant local repos from all other sites)
Developers then pull from "foo" and deploy either to some "foo-local" or, with
Artifactory 4.x, also just deploy to the virtual "foo" which is configured to
deploy by default to one of the "foo-local" repos.
This avoids having site A's remote view of site B include any remotes at B
which point back to A. If you have that then, depending on repository order,
you can end up with server A finding some path matches first in a remote of
some repo at B, and that match at B is in a remote which points back to A, but
the path isn't yet cached at B. At that point you'll get a 404 because caching
of remote artifacts doesn't "chain" across servers.
At least, that's how we do it. If someone can suggest a simpler way, I'm happy
to hear it :-)
Regards,
Hugh Greene
Senior Software Developer
Toshiba Medical Visualization Systems Europe, Ltd
Bonnington Bond, 2 Anderson Place, Edinburgh EH6 5NP, UK
P 44 (0)131 472 4792 | F + 44 (0) 131 472 4799
E mailto:[email protected] | W http://www.tmvse.com<http://www.tmvse.com/>
DISCLAIMER
Unless indicated otherwise, the information contained in this message is
privileged and confidential, and is intended only for the use of the
addressee(s) named above and others who have been specifically authorized to
receive it. If you are not the intended recipient, you are hereby notified that
any dissemination, distribution or copying of this message and/or attachments
is strictly prohibited. The company accepts no liability for any damage caused
by any virus transmitted by this email. Furthermore, the company does not
warrant a proper and complete transmission of this information, nor does it
accept liability for any delays. If you have received this message in error,
please contact the sender and delete the message.
From: O'Connell, Ken [mailto:[email protected]]
Sent: 23 August 2016 21:24
To: [email protected]
Subject: [Artifactory-users] replication endpoint urls and Git LFS
Good day all,
We are trying to understand exactly how we can ensure objects/ artifacts (once
they are replicated to remote Artifactory instance) will be pulled from remote
Artifactory instance that is local to the replicated location, and not from the
original server where the object was originally deployed.
We want to ensure users (as well as our automated build scripts) in Europe will
pull (new/ changed) objects that were replicated to European Artifactory
servers, and will NOT be pulled from the Artifactory server back in the United
States where the original local repo resides.
How is that typically done? How are the different repository types (local,
remote, virtual) used in this setup?
i.e.
* Developer 1 (US): -creates a SCM repo (in
Bitbucket) with a .lfsconfig file containing the 'local-testrepo' url for
Artifactory.
[lfs]
url = "http://artifactory:XXXX/artifactory/api/lfs/extern-local";
* Developer 1 (US): -pushes new or changed
code that lands in the US local-testrepo, and is then replicated to Europe
Artifactory server repo.
* Developer 2 (EU): -retrieves the new code
from European Artifactory server
o Automated script: -retrieves the new code from European
Artifactory server
* Developer 2 (EU): -pushes his code changes
to European Artifactory server (which are replicated back to US, OR are pushed
(via git) directly back to US)
Thanks for any help you can provide, and please let me know if you need further
info.
-K
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
------------------------------------------------------------------------------
_______________________________________________
Artifactory-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
