Bug 1258943

Summary: yum_repos URLs miss the project name
Product: [Community] Copr Reporter: Radek Holy <rholy>
Component: frontendAssignee: Jakub Kadlčík <jkadlcik>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: urgent Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: jzeleny, msuchy, praiskup
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-10-15 09:45:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Radek Holy 2015-09-01 14:43:34 UTC
(please note that I'm not really sure what is the correct component)

Description of problem:
The yum_repos URLs provided by the REST API and Python API miss the project name which means that they point to a non-existent location.


Version-Release number of selected component (if applicable):
I don't know the version, it's the one that is running at https://copr.fedoraproject.org/.
Copr frontend build version: 1.66-1.fc21 


How reproducible:
always


Steps to Reproduce:
1. GET https://copr.fedoraproject.org/api/coprs/rholy/dnf/detail/


Actual results:
{
  "detail": {
    "additional_repos": "", 
    "auto_createrepo": true, 
    "description": "", 
    "instructions": "", 
    "last_modified": 1441106693, 
    "name": "dnf", 
    "yum_repos": {
      "fedora-22-i386": "https://copr-be.cloud.fedoraproject.org/results/rholy/fedora-22-i386/", 
      "fedora-22-x86_64": "https://copr-be.cloud.fedoraproject.org/results/rholy/fedora-22-x86_64/", 
      "fedora-23-i386": "https://copr-be.cloud.fedoraproject.org/results/rholy/fedora-23-i386/", 
      "fedora-23-x86_64": "https://copr-be.cloud.fedoraproject.org/results/rholy/fedora-23-x86_64/", 
      "fedora-rawhide-i386": "https://copr-be.cloud.fedoraproject.org/results/rholy/fedora-rawhide-i386/", 
      "fedora-rawhide-x86_64": "https://copr-be.cloud.fedoraproject.org/results/rholy/fedora-rawhide-x86_64/"
    }
  }, 
  "output": "ok"
}


Expected results:
{
  "detail": {
    "additional_repos": "", 
    "auto_createrepo": true, 
    "description": "", 
    "instructions": "", 
    "last_modified": 1441106693, 
    "name": "dnf", 
    "yum_repos": {
      "fedora-22-i386": "https://copr-be.cloud.fedoraproject.org/results/rholy/dnf/fedora-22-i386/", 
      "fedora-22-x86_64": "https://copr-be.cloud.fedoraproject.org/results/rholy/dnf/fedora-22-x86_64/", 
      "fedora-23-i386": "https://copr-be.cloud.fedoraproject.org/results/rholy/dnf/fedora-23-i386/", 
      "fedora-23-x86_64": "https://copr-be.cloud.fedoraproject.org/results/rholy/dnf/fedora-23-x86_64/", 
      "fedora-rawhide-i386": "https://copr-be.cloud.fedoraproject.org/results/rholy/dnf/fedora-rawhide-i386/", 
      "fedora-rawhide-x86_64": "https://copr-be.cloud.fedoraproject.org/results/rholy/dnf/fedora-rawhide-x86_64/"
    }
  }, 
  "output": "ok"
}


Additional info:
Originally, I hit this when trying to get the URL of the results using the Python "API":
    from copr.client import CoprClient
    cl = CoprClient.create_from_file_config()
    prj = cl.get_project_details('dnf')
    print(prj.data['detail']['yum_repos'])

I guess that the problem is either here: https://git.fedorahosted.org/cgit/copr.git/tree/frontend/coprs_frontend/coprs/views/api_ns/api_general.py#n199 or somewhere in repo.builds[index].results.

I believe that the issue is really important since it is in conflict with the documentation and since it is really difficult to work around it. I am also wondering about creating a ticket against the running Copr to be able track the problem.

Comment 1 Jakub Kadlčík 2015-09-02 11:12:07 UTC
Hello Radek, thank you for the detailed description. As you expected, the problem was in this line: urlparse.urljoin(build.results, release + '/'))

Modified in: c5dcbbc

Comment 2 Radek Holy 2015-09-02 11:40:26 UTC
Thank you very much for looking at it!

Can you estimate the time when the fix will be deployed on the production server?

Comment 4 Miroslav Suchý 2015-10-15 09:45:56 UTC
Version with this fix has been just deployed to production.