[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21601#comment-21601
 ] 

Barak Korren edited comment on OVIRT-751 at 10/6/16 3:20 PM:
-------------------------------------------------------------

This is something a project can decide to do on its own by simply bind-mounting 
a known location into the chroot (with the *.mounts file).
You can either have a per-job cache by mounting from under $WORKSPACE, or a 
global per-slave cache by mounting from under /home/jenkins


was (Author: [email protected]):
This is something a project can decide to do on its own by simply bind-mounting 
a known location into the chroot (with the *.mounts) file.
You can either have a per-job cache by mounting from under $WORKSPACE, or a 
global per-slave cache by mounting from under /home/jenkins

> Persistent maven caches on the mock slaves
> ------------------------------------------
>
>                 Key: OVIRT-751
>                 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-751
>             Project: oVirt - virtualization made easy
>          Issue Type: Improvement
>            Reporter: Anton Marchukov
>            Assignee: infra
>
> I think we need to design a way to retain maven caches on the mocked jenkins 
> slaves. Currently it is stored inside the mock and thus maven downloads 
> packages from artifactory server each time. 
> However there is really no reason for that. Maven artifacts are designed to 
> be immutable so once artifact is in the repo there is no trivial way to 
> change it without creating a new version. In fact it should never be needed 
> and the correct solution for that is to always create a new version.
> SNAPSHOOT artifacts are in fact timestamped and each one have different file 
> name. It is just not visible since maven automatically takes the latest one. 
> But it is not related to caching as the new snapshoot will be a new artifact 
> still.
> So based on that point there is no reason to purge maven cache each time, but 
> there are reasons why not to purge. Not purging them will reduce the build 
> times of all java jobs and also reduce the network traffic we have. 



--
This message was sent by Atlassian JIRA
(v1000.383.2#100014)
_______________________________________________
Infra mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/infra

Reply via email to