pycontribs / jenkinsapi

A Python API for accessing resources and configuring Hudson & Jenkins continuous-integration servers
http://pypi.python.org/pypi/jenkinsapi
MIT License
858 stars 483 forks source link

Breaking change in 0.3.11 for top-level jobs #747

Open mattdowdell opened 4 years ago

mattdowdell commented 4 years ago
ISSUE TYPE
Jenkinsapi VERSION
Jenkins VERSION
SUMMARY

v0.3.11 appear to contain a breaking change for non-pipeline jobs. For example, I currently see the following exception:

  File "./get-smoke-tested-build.py", line 54, in find_build
    job = jenkins[job_name]
  File "/home/matt/repos/repobj-ci/scripts/venv/lib/python3.7/site-packages/jenkinsapi/jenkins.py", line 269, in __getitem__
    return self.jobs[jobname]
  File "/home/matt/repos/repobj-ci/scripts/venv/lib/python3.7/site-packages/jenkinsapi/jobs.py", line 89, in __getitem__
    raise UnknownJob(job_name)
jenkinsapi.custom_exceptions.UnknownJob: 'Gen4_PythonWrapper_Smoke_VSA_alley_cat'

The job however does exist, but is apparently being output in a different format:

('<hostname>/Gen4_PythonWrapper_Smoke_VSA_alley_cat', <jenkinsapi.job.Job Gen4_PythonWrapper_Smoke_VSA_alley_cat>)

The hostname appears to be whatever the value of JENKINS_URL is. As a side note, the URL is wrong and misses the /job part of the path and probably more bits as well.

Jobs that are from multibranch pipelines or in folders do show up as I'd expect:

('ClientLibrary_gen4_trunk_PR/PR-142', <jenkinsapi.job.Job PR-142>)
('matt_sandbox/viridian/master', <jenkinsapi.job.Job master>)

I suspect the difference is caused by https://github.com/pycontribs/jenkinsapi/pull/740/files#diff-c3acba40d83dadf1f3feabe769b8db86L113

EXPECTED RESULTS

I'd expect that the intended fix of #740 to work, but not for it to affect top level jobs.

ACTUAL RESULTS

N/A

USEFUL INFORMATION

N/A

lechat commented 4 years ago

The job however does exist, but is apparently being output in a different format:

Could you explain where is that output coming from?

mattdowdell commented 4 years ago

Sure:

from jenkinsapi.jenkins import Jenkins

jenkins_url = 'https://example.org/jenkins'
jenkins = Jenkins(jenkins_url, ssl_verify=False)

print([x for x in jenkins.get_jobs()])

# this is where I see the exception
job = jenkins[job_name]

I'm working on the assumption that get_jobs and contains use the same source for their jobs. Looking back I'm not entirely sure that's the case.

chrismaes87 commented 4 years ago

I have been playing around and was able to reproduce your problem: If I create the Jenkins instance with our fully qualified name:

J = jenkinsapi.jenkins.Jenkins("http://jenkins.domain/")

then indeed all jobs get the wrong prefix:

'http:/jenkins/job-name'

however if I use the name without domain (which is also the url configured), then the job names are correct:

J = jenkinsapi.jenkins.Jenkins("http://jenkins/")

changing the url (in jenkins/configure) to http://jenkins.domain made it also work with:

J = jenkinsapi.jenkins.Jenkins("http://jenkins.domain/")
ChrisSchneebauer commented 4 years ago

We're having the same problem, but providing the domain did not help. Jenkinsapi version 0.3.10 is working fine.

chrismaes87 commented 4 years ago

@ChrisSchneebauer : You don't just need to provide the domain, it seems like you need to align:

lechat commented 4 years ago

I think that it is good change because it forced people to configure Jenkins how it should be configured. Perhaps I will add a test for this case, to show people that code will fail if Jenkins URL is not set correctly.

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

J3ronimo commented 3 years ago

You don't just need to provide the domain, it seems like you need to align:

* the name you use in your constructor> 
* the URL configured under your jenkins/configure (_Jenkins URL_)

... including upper or lower case, that's what was my problem as it turned out.

While I agree that they should be the same otherwise, requiring the same case is overkill IMHO. Think of Jenkins instances running on a host in a LAN. Quite often you'd have your hostname in upper case, like MYBUILDSERVER, but as soon as you type that into your browser's address bar, it's turned into "http://mybuildserver/". There's nothing that enforces a certain case here, nor anywhere else in Jenkins or jenkinsapi. And even if it's decided to force it here, there should be a proper error message, not just some corrupted buildjob name / key in the Jenkins.jobs dict. Btw this also breaks Jenkins.create_job, because it can't find the job it just created when trying to return it at the end...

ppi-agray commented 11 months ago

We got bit by this too. We have the following setup: CNAME->Public-ALB(cert termination)->Jenkins Instance. In Jenkins/Configure, the URL is the https public CNAME.

But within the VPC, we can hit the jenkins instance directly correctly via the IP address of the instance.

For this reason, the jenkinsapi package fails to list out the correct job names. It works when using the registered CNAME, but fails when using the internal ip address of jenkins.

In my opinion, this is a bug. Getting the list of jobs, should get the list of jobs period, regardless of what URL you are using to access Jenkins.