Unable to launch job

[ckonstanski]

I can do most other actions that require an HTTP request, but I cannot launch a job. Packet trace:

POST /job/manage-pubkeys/build HTTP/1.1
MIME-Version: 1.0
Extension: Security/Digest Security/SSL
Host: openbook-jenkins-master.mon.vzwops.com
Accept-encoding: gzip
Accept-charset: utf-8;q=1, gb2312;q=0.5, iso-8859-1;q=0.5, big5;q=0.5, iso-2022-jp;q=0.5, shift_jis;q=0.5, euc-tw;q=0.5, euc-jp;q=0.5, euc-jis-2004;q=0.5, euc-kr;q=0.5, iso-8859-15;q=0.5, us-ascii;q=0.5, utf-7;q=0.5, hz-gb-2312;q=0.5, big5-hkscs;q=0.5, gbk;q=0.5, gb18030;q=0.5, iso-8859-5;q=0.5, koi8-r;q=0.5, koi8-u;q=0.5, cp866;q=0.5, koi8-t;q=0.5, windows-1251;q=0.5, cp855;q=0.5, iso-8859-2;q=0.5, iso-8859-3;q=0.5, iso-8859-4;q=0.5, iso-8859-9;q=0.5, iso-8859-10;q=0.5, iso-8859-13;q=0.5, iso-8859-14;q=0.5, windows-1250;q=0.5, windows-1252;q=0.5, windows-1254;q=0.5, windows-1257;q=0.5, cp775;q=0.5, cp850;q=0.5, cp852;q=0.5, cp857;q=0.5, cp858;q=0.5, cp860;q=0.5, cp861;q=0.5, cp863;q=0.5, cp865;q=0.5, cp437;q=0.5, macintosh;q=0.5, next;q=0.5, hp-roman8;q=0.5, adobe-standard-encoding;q=0.5, iso-8859-16;q=0.5, iso-8859-7;q=0.5, windows-1253;q=0.5, cp737;q=0.5, cp851;q=0.5, cp869;q=0.5, iso-8859-8;q=0.5, windows-1255;q=0.5, cp862;q=0.5, iso-2022-jp-2004;q=0.5, cp874;q=0.5, iso-8859-11;q=0.5, viscii;q=0.5, windows-1258;q=0.5, iso-8859-6;q=0.5, windows-1256;q=0.5, iso-2022-cn;q=0.5, iso-2022-cn-ext;q=0.5, iso-2022-jp-2;q=0.5, iso-2022-kr;q=0.5, utf-16le;q=0.5, utf-16be;q=0.5, utf-16;q=0.5, x-ctext;q=0.5
Accept: /
User-Agent: URL/Emacs
Cookie: JSESSIONID.05b82c0d=node05zkb3yhhjgal1qwipubu55rac7.node0; HttpOnly=nil
Content-Type: application/x-www-form-urlencoded
Authorization: Basic [auth data retracted]
X-Forwarded-Proto: https
X-Forwarded-For: 10.134.10.212

HTTP/1.1 403 No valid crumb was included in the request
Date: Mon, 12 Mar 2018 20:42:02 GMT
Server: Jetty(9.4.z-SNAPSHOT)
X-Content-Type-Options: nosniff
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=utf-8
Content-Length: 405

<title>Error 403 No valid crumb was included in the request</title>

HTTP ERROR 403

Problem accessing /job/manage-pubkeys/build. Reason:

    No valid crumb was included in the request

---

Powered by Jetty:// 9.4.z-SNAPSHOT

---

[ckonstanski]

I turned off HTTP/2.0 and still have the issue. A slightly different packet trace:

POST /job/manage-pubkeys/build HTTP/1.1
MIME-Version: 1.0
Extension: Security/Digest Security/SSL
Host: openbook-jenkins-master.mon.vzwops.com
Accept-encoding: gzip
Accept-charset: utf-8;q=1, gb2312;q=0.5, iso-8859-1;q=0.5, big5;q=0.5, iso-2022-jp;q=0.5, shift_jis;q=0.5, euc-tw;q=0.5, euc-jp;q=0.5, euc-jis-2004;q=0.5, euc-kr;q=0.5, iso-8859-15;q=0.5, us-ascii;q=0.5, utf-7;q=0.5, hz-gb-2312;q=0.5, big5-hkscs;q=0.5, gbk;q=0.5, gb18030;q=0.5, iso-8859-5;q=0.5, koi8-r;q=0.5, koi8-u;q=0.5, cp866;q=0.5, koi8-t;q=0.5, windows-1251;q=0.5, cp855;q=0.5, iso-8859-2;q=0.5, iso-8859-3;q=0.5, iso-8859-4;q=0.5, iso-8859-9;q=0.5, iso-8859-10;q=0.5, iso-8859-13;q=0.5, iso-8859-14;q=0.5, windows-1250;q=0.5, windows-1252;q=0.5, windows-1254;q=0.5, windows-1257;q=0.5, cp775;q=0.5, cp850;q=0.5, cp852;q=0.5, cp857;q=0.5, cp858;q=0.5, cp860;q=0.5, cp861;q=0.5, cp863;q=0.5, cp865;q=0.5, cp437;q=0.5, macintosh;q=0.5, next;q=0.5, hp-roman8;q=0.5, adobe-standard-encoding;q=0.5, iso-8859-16;q=0.5, iso-8859-7;q=0.5, windows-1253;q=0.5, cp737;q=0.5, cp851;q=0.5, cp869;q=0.5, iso-8859-8;q=0.5, windows-1255;q=0.5, cp862;q=0.5, iso-2022-jp-2004;q=0.5, cp874;q=0.5, iso-8859-11;q=0.5, viscii;q=0.5, windows-1258;q=0.5, iso-8859-6;q=0.5, windows-1256;q=0.5, iso-2022-cn;q=0.5, iso-2022-cn-ext;q=0.5, iso-2022-jp-2;q=0.5, iso-2022-kr;q=0.5, utf-16le;q=0.5, utf-16be;q=0.5, utf-16;q=0.5, x-ctext;q=0.5
Accept: /
User-Agent: URL/Emacs
Content-Type: application/x-www-form-urlencoded
Authorization: Basic a29uc3RjYTozZGVlZTdhMzMyNzhlNGQxNzBkNDEzZGUyM2UyYWNmZQ==
X-Forwarded-Proto: https
X-Forwarded-For: 10.134.10.212

HTTP/1.1 403 No valid crumb was included in the request
Date: Mon, 12 Mar 2018 21:44:44 GMT
Server: Jetty(9.4.z-SNAPSHOT)
X-Content-Type-Options: nosniff
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=utf-8
Content-Length: 405

<title>Error 403 No valid crumb was included in the request</title>

HTTP ERROR 403

Problem accessing /job/manage-pubkeys/build. Reason:

    No valid crumb was included in the request

---

Powered by Jetty:// 9.4.z-SNAPSHOT

---

[andreyij]

The plugin's implementation seems to expect that sending a POST request to "jenkins-url/job-name/build" with no body will work. I do not think it is the case with latest Jenkins versions (at least for the version I am using). I think there are three options:

1. Modify jenkins.el in order to trigger a parametrized build with the POST request (https://wiki.jenkins.io/display/JENKINS/Remote+access+API#RemoteaccessAPI-SubmittingJobs) as well as make use of the CSRF protection (https://wiki.jenkins.io/display/JENKINS/Remote+access+API#RemoteaccessAPI-CSRFProtection)

2. Modify jenkins.el in order to trigger a parametrized build with the POST request (https://wiki.jenkins.io/display/JENKINS/Remote+access+API#RemoteaccessAPI-SubmittingJobs) and disable CSRF protection - which is not quite recommended (https://wiki.jenkins.io/display/JENKINS/CSRF+Protection)

3. Use the Rebuild Plugin (https://wiki.jenkins.io/display/JENKINS/Rebuild+Plugin) and mark the job you want to trigger as Rebuild without asking for parameters. Then you can just modify the jenkins.el to send a GET request to "jenkins-url/job-name/lastCompletedBuild/rebuild"

[ckonstanski]

FWIW I disabled CSRF in my jenkins. It would give a similar (identical?) error if enabled. That potential issue is eliminated. I'm on version 2.207.1.

[andreyij]

My experience was similar on version 2.107
With CSRF disabled are not getting a error similar to this one below?
javax.servlet.ServletException:This page expects a form submission but had only {}

If this is the case, then have you tried running it on a job that requires no parameters to build?
If with CSRF disabled you still receive the

No valid crumb was included in the request

error, than I think something else is wrong with the configuration.

[ckonstanski]

Now I get "400 nothing is submitted".

POST /job/ob-ctl-restart-unstable/build HTTP/1.1
MIME-Version: 1.0
Extension: Security/Digest Security/SSL
Host: openbook-jenkins-master.mon.vzwops.com
Accept-encoding: gzip
Accept-charset: utf-8;q=1, gb2312;q=0.5, iso-8859-1;q=0.5, big5;q=0.5, iso-2022-jp;q=0.5, shift_jis;q=0.5, euc-tw;q=0.5, euc-jp;q=0.5, euc-jis-2004;q=0.5, euc-kr;q=0.5, iso-8859-15;q=0.5, us-ascii;q=0.5, utf-7;q=0.5, hz-gb-2312;q=0.5, big5-hkscs;q=0.5, gbk;q=0.5, gb18030;q=0.5, iso-8859-5;q=0.5, koi8-r;q=0.5, koi8-u;q=0.5, cp866;q=0.5, koi8-t;q=0.5, windows-1251;q=0.5, cp855;q=0.5, iso-8859-2;q=0.5, iso-8859-3;q=0.5, iso-8859-4;q=0.5, iso-8859-9;q=0.5, iso-8859-10;q=0.5, iso-8859-13;q=0.5, iso-8859-14;q=0.5, windows-1250;q=0.5, windows-1252;q=0.5, windows-1254;q=0.5, windows-1257;q=0.5, cp775;q=0.5, cp850;q=0.5, cp852;q=0.5, cp857;q=0.5, cp858;q=0.5, cp860;q=0.5, cp861;q=0.5, cp863;q=0.5, cp865;q=0.5, cp437;q=0.5, macintosh;q=0.5, next;q=0.5, hp-roman8;q=0.5, adobe-standard-encoding;q=0.5, iso-8859-16;q=0.5, iso-8859-7;q=0.5, windows-1253;q=0.5, cp737;q=0.5, cp851;q=0.5, cp869;q=0.5, iso-8859-8;q=0.5, windows-1255;q=0.5, cp862;q=0.5, iso-2022-jp-2004;q=0.5, cp874;q=0.5, iso-8859-11;q=0.5, viscii;q=0.5, windows-1258;q=0.5, iso-8859-6;q=0.5, windows-1256;q=0.5, iso-2022-cn;q=0.5, iso-2022-cn-ext;q=0.5, iso-2022-jp-2;q=0.5, iso-2022-kr;q=0.5, utf-16le;q=0.5, utf-16be;q=0.5, utf-16;q=0.5, x-ctext;q=0.5
Accept: */*
User-Agent: URL/Emacs
Content-Type: application/x-www-form-urlencoded
Authorization: Basic xxxxxxxxxxxx==
X-Forwarded-Proto: https
X-Forwarded-For: 10.134.10.240

HTTP/1.1 400 Nothing is submitted
Date: Wed, 21 Mar 2018 00:00:07 GMT
Server: Jetty(9.4.z-SNAPSHOT)
X-Content-Type-Options: nosniff
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=utf-8
Content-Length: 370
Connection: close

<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
<title>Error 400 Nothing is submitted</title>
</head>
<body><h2>HTTP ERROR 400</h2>
<p>Problem accessing /job/ob-ctl-restart-unstable/build. Reason:
<pre>    Nothing is submitted</pre></p><hr><a href="http://eclipse.org/jetty">Powered by Jetty:// 9.4.z-SNAPSHOT</a><hr/>

</body>
</html>

[rmuslimov]

I'm sorry that I'm not helping you with solving the issue, I will check this weekend.

[andreyij]

Yes, you are receiving that error because most likely you job named ob-ctl-restart-unstable requires some parameters. Is this true?
If it does require parameters, then one quick solution (which worked for me, since I am not sure if the emacs plugin allows sending these parameters) is to install the Rebuild Plugin in Jenkins. This allows you to run the last build with the parameters used at that time, without sending them again.

[ckonstanski]

You know what, you are right. This particular job does require a parameter. I wasn't thinking of it because it is an "optional" parameter in that I usually leave it blank. But jenkins doesn't know that.

I just tested with a different job that takes no parameters. It works!

The ability to run a job that takes parameters would be a nice-to-have, but that's a separate issue. Between parameters and disabling CSRF I'd say this issue is solved. Those are potential TODO items in their own right.

[xiaocai2333]

I had the same problem with you, and I was just trying to get the build in Jenkins to the terminal，do you know how to do it?

[chumaltd]

This is just API endpoint issue, which is diffent between parameterized and non parameterized.
You can test jenkins.el modification.

        ; Works with non parameterized build job
        (build-url (format "%sjob/%s/build" (get-jenkins-url) jobname)))
        ; Works with parameterized build job
        (build-url (format "%sjob/%s/buildWithParameters" (get-jenkins-url) jobname)))

No parameters request runs with default parameters.
This works almost well, but we can't figure out each job is whether parameterized or not via API.
Calling both endpoints may be a practical solution.