[RTFACT-14496] Artifactory should accept primary.xml.gz in a repodata Created: 29/Jun/17  Updated: 16/Mar/19

Status: Open
Project: Artifactory Binary Repository
Component/s: RPM, YUM
Affects Version/s: 5.4.1
Fix Version/s: None

Type: Improvement Priority: Normal
Reporter: Aviv Blonder Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None


 Description   

To reproduce:

  • Create 2 remote repositories:
    1. http://fedora.mirrors.pair.com/epel/6/x86_64/
    2. http://mirrors.kernel.org/ius/stable/Redhat/6/x86_64/
  • Add them to a virtual repository.
  • Create the artifactory.repo for this virtual repo using the set me up.
  • As the repodata of the 2nd remote repo contain primary.xml.gz (zipped), the metadata merge fails. (Artifactory expects primary.xml)
    2017-06-29 17:57:21,941 [art-exec-1295] [DEBUG] (o.a.a.y.v.i.YumVirtualIndexesCollector:257) - Can't resolve index paths from repomd.xml at path centos/repodata/repomd.xml: No entry for primary.xml index found in repomd.xml in location: centos/repodata/
    java.lang.Exception: No entry for primary.xml index found in repomd.xml in location: centos/repodata/
    	at org.artifactory.addon.yum.virtual.resolve.YumIndexPathsResolver.findIndexLocationEntry(YumIndexPathsResolver.java:68) ~[artifactory-addon-yum-5.4.1.jar:na]
    	at org.artifactory.addon.yum.virtual.resolve.YumIndexPathsResolver.resolve(YumIndexPathsResolver.java:51) ~[artifactory-addon-yum-5.4.1.jar:na]
    	at org.artifactory.addon.yum.virtual.index.YumVirtualIndexesCollector.resolveIndexPaths(YumVirtualIndexesCollector.java:247) [artifactory-addon-yum-5.4.1.jar:na]
    	at org.artifactory.addon.yum.virtual.index.YumVirtualIndexesCollector.collectIndexesFromAggregatedRepos(YumVirtualIndexesCollector.java:193) [artifactory-addon-yum-5.4.1.jar:na]
    	at org.artifactory.addon.yum.virtual.index.YumVirtualIndexesCollector.collect(YumVirtualIndexesCollector.java:62) [artifactory-addon-yum-5.4.1.jar:na]
    	at org.artifactory.addon.yum.virtual.index.YumVirtualCalculatorImpl.calculateYumVirtualMetadata(YumVirtualCalculatorImpl.java:66) [artifactory-addon-yum-5.4.1.jar:na]
    	at org.artifactory.addon.yum.virtual.index.YumVirtualCalculatorImpl.calculateYumVirtualMetadata(YumVirtualCalculatorImpl.java:47) [artifactory-addon-yum-5.4.1.jar:na]
    	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_111]
    	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_111]
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_111]
    	at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_111]
    	at org.artifactory.work.queue.AsyncWorkQueueServiceImpl.lambda$0(AsyncWorkQueueServiceImpl.java:69) [artifactory-core-5.4.1.jar:na]
    	at org.artifactory.work.queue.WorkQueueImpl.doJobs(WorkQueueImpl.java:81) ~[artifactory-core-5.4.1.jar:na]
    	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[na:1.8.0_111]
    	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_111]
    	at org.artifactory.schedule.ArtifactoryConcurrentExecutor$RunnableWrapper.run(ArtifactoryConcurrentExecutor.java:104) ~[artifactory-storage-common-5.4.1.jar:na]
    	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[na:1.8.0_111]
    	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ~[na:1.8.0_111]
    	at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_111]
    
  • Because of this, you will only be able to resolve from the first remote repo in the order of the virtual repo.

Workaround:

  • Create multiple .repo files, one for each remote repo.
    For example, centos.repo and fedora.repo


 Comments   
Comment by Janis Balodis [ 14/Nov/18 ]

I am experiencing the same problem on v 6.5.2. Addition of local rpm repositories to virtual works perfectly, though.

Generated at Tue Oct 22 23:43:17 UTC 2019 using JIRA 7.6.16#76018-sha1:9ed376192612a49536ac834c64177a0fed6290f5.