[JIRA] (OVIRT-751) Persistent maven caches on the mock slaves

eyal edri [Administrator] (oVirt JIRA) jira at ovirt-jira.atlassian.net
Mon Oct 31 08:20:03 UTC 2016


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

eyal edri [Administrator] commented on OVIRT-751:
-------------------------------------------------

I think we should give it a try for ovirt-engine and be proactive on this, since it also serve us as it will reduce load on network and jenkins server and also reduce feedback time to check-patch jobs. 
If its a simple patch, lets just send it and check it out, shouldn't take too much time. 

> 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.482.3#100017)



More information about the Infra mailing list