Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Wait for Jenkins to start" is broken with e.g. Google OAuth #56

Open
hasufell opened this issue Nov 22, 2019 · 7 comments
Open

"Wait for Jenkins to start" is broken with e.g. Google OAuth #56

hasufell opened this issue Nov 22, 2019 · 7 comments

Comments

@hasufell
Copy link
Contributor

hasufell commented Nov 22, 2019

Expected Behavior

The "Wait for Jenkins to start" task succeeds.

Actual Behavior

It doesn't succeed.

Steps to Reproduce the Problem

  1. configure jenkins with google oauth
  2. redeploy

Explanation

The main url returns 403 when google oauth is configured. But I think it is actually timing out... from within the playbook it never succeeds nor returns, even after I changed it to:

---
- include_tasks: "{{ jenkins_install_via }}/start.yml"

- name: Wait for Jenkins to start
  uri:
    url: "{{ jenkins_url }}"
    validate_certs: "{{ jenkins_https_validate_certs }}"
    status_code: [200, 403, 503]
    timeout: 5
  become: false
  register: jenkins_home_content
  # Jenkins will return 503 (service unavailable) on the home page while
  # starting (the "Please wait while Jenkins is getting ready to work" page)
  until: not (jenkins_home_content.status == 503)
  retries: 5
  delay: 5
@nre-ableton
Copy link
Contributor

I'm not familiar with this specific Jenkins plugin, but if it's anything like the AD plugin, it should allow one system account as a fallback in case of network glitches/outages. Have you configured such an account?

Also, after Ansible times out, can you visit the Jenkins site in a regular web browser? What do you see? Did it start up normally?

Finally, some logging output with at -vvv verbosity would be helpful.

@hasufell
Copy link
Contributor Author

hasufell commented Nov 22, 2019

I'm not familiar with this specific Jenkins plugin, but if it's anything like the AD plugin, it should allow one system account as a fallback in case of network glitches/outages. Have you configured such an account?

No and it isn't desired. I think we have bigger problems if google has an outage.

Also, after Ansible times out, can you visit the Jenkins site in a regular web browser? What do you see? Did it start up normally?

Yes.

It appears the playbook configuration is just not powerful enough, it silently overwrites my jenkins_url and I cannot change it:

# Previous versions of this role defined jenkins_url as a default variable, but this URL
# did not include the port, and required the user to hard-code the protocol.
- name: Set jenkins_url fact for backwards-compatibility installations
  set_fact:
    jenkins_url: "{{ jenkins_url }}:{{ jenkins_port }}"
  when: jenkins_url is defined

Since jenkins_port only refers to the port jenkins runs on, not the port the machine is exposed at... this breaks things.

@nre-ableton
Copy link
Contributor

nre-ableton commented Nov 22, 2019

Yes, you should not set jenkins_url. You need to set jenkins_hostname instead, and jenkins_url will be automatically set depending on the protocol and port. If you need to set a Jenkins location to something different than what is used during provisioning, I would recommend making your own template of jenkins.model.JenkinsLocationConfiguration.xml.j2 and adding it to jenkins_custom_files (don't forget to set jenkins_include_custom_files to true!).

I do a similar thing for one of my Jenkins installations, since we need to configure authbind after Jenkins and need to change the port after this role completes.

@hasufell
Copy link
Contributor Author

I don't need a different URL. I need a different port. I would argue it's quite a big assumption that the port used for starting Jenkins is the same used for accessing the instance from the outside.

@nre-ableton
Copy link
Contributor

I don't need a different URL. I need a different port. I would argue it's quite a big assumption that the port used for starting Jenkins is the same used for accessing the instance from the outside.

So part of the reason that jenkins_url was externally deprecated is that this variable was meant to contain the protocol, but not the port. This made it quite difficult to support HTTPS, not to mention that the name was a bit deceptive since technically the port is considered part of the URL.

But again, if you specify the external URL for Jenkins in jenkins.model.JenkinsLocationConfiguration.xml.j2, this should fix this issue for you.

@hasufell
Copy link
Contributor Author

hasufell commented Nov 25, 2019

But again, if you specify the external URL for Jenkins in jenkins.model.JenkinsLocationConfiguration.xml.j2, this should fix this issue for you.

I don't have that file and don't know what that is.

The problem is not jenkinsUrl at all it is:

  • the app must be started at port 8080 (which is controlled by jenkins_port, not by JenkinsLocationConfiguration)
  • during health check, jenkins_url must not have the port, but I cannot control it

@nre-ableton
Copy link
Contributor

But again, if you specify the external URL for Jenkins in jenkins.model.JenkinsLocationConfiguration.xml.j2, this should fix this issue for you.

I don't have that file and don't know what that is.

You can find a copy either on your Jenkins instance in JENKINS_HOME, or you can borrow the one in this repository. This version of course uses jenkins_url, but you could change this to some other var containing the external URL that you need to use.

The problem is not jenkinsUrl at all it is:

* the app must be started at port 8080 (which is controlled by `jenkins_port`, not by JenkinsLocationConfiguration)

* during health check, `jenkins_url` must not have the port, but I cannot control it

I'm unfamiliar with the health check, but I googled a bit and am guessing that it is associated with the Google OAuth plugin? When does it occur exactly?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants