[JIRA] [workflow-plugin] (JENKINS-33020) Unable to Trigger builds remotely (e.g., from scripts)
Title: Message Title Gijs Kunze commented on JENKINS-33020 Re: Unable to Trigger builds remotely (e.g., from scripts) Hmm, it must be another plugin that causes the option to be there then, because I definitely have the option. Could be the "Build Token Root Plugin" Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [github-branch-source-plugin] (JENKINS-35185) Trigger github multi-branch build via SQS
Title: Message Title Gijs Kunze created an issue Jenkins / JENKINS-35185 Trigger github multi-branch build via SQS Issue Type: Bug Assignee: Jesse Glick Components: github-branch-source-plugin, github-sqs-plugin, multi-branch-project-plugin Created: 2016/May/27 1:59 PM Priority: Minor Reporter: Gijs Kunze It would be nice if we could automatically trigger multi-branch projects with the SQS plugin just like we can trigger old-style jobs. (We run our jenkins server in our intranet so we can't use the webhook). (I hope I selected the correct components, apologies if I made a mistake) Add Comment
[JIRA] [workflow-plugin] (JENKINS-33020) Unable to Trigger builds remotely (e.g., from scripts)
Title: Message Title Gijs Kunze commented on JENKINS-33020 Re: Unable to Trigger builds remotely (e.g., from scripts) I'm affected by this as well (both in Jenkins 2.0 and 2.6, multibranch plugin 2.4) using a github source but even if I specify no source at all the trigger setting doesn't persist. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ec2-plugin] (JENKINS-32779) Spot instance hit cap when sharing a AMI
Title: Message Title Gijs Kunze commented on JENKINS-32779 Re: Spot instance hit cap when sharing a AMI I have the same issue, but it seems to be similar to JENKINS-32584 because if other (unrelated, not the same AMI or instance tags or anything) spot instances are running my jenkins server doesn't start any and jobs never get processed. I've reverted to 1.29 so my builds work again. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [docker-commons-plugin] (JENKINS-34503) Add username/password support for docker registry
Title: Message Title Gijs Kunze created an issue Jenkins / JENKINS-34503 Add username/password support for docker registry Issue Type: New Feature Assignee: Jesse Glick Components: docker-commons-plugin, docker-workflow-plugin Created: 2016/Apr/29 8:09 AM Labels: workflow docker Priority: Minor Reporter: Gijs Kunze Currently with the docker workflow plugin you have to specify credentials, however in our case we're using the AWS's container registry which don't have fixed credentials. Instead, you can use an AWS api call to retrieve temporary credentials (valid 12 hours). Ideally, a three-parameter withRegistry (registry, username, password) would allow us to log in with these kinds of credentials. Add Comment
[JIRA] [docker-workflow-plugin] (JENKINS-34503) Add username/password support for docker registry
Title: Message Title
Gijs Kunze commented on JENKINS-34503
Re: Add username/password support for docker registry
AWS has it's own authentication system. To more completely describe the situation:
We have a small master (no executors) and by default, no slaves. Slaves are automatically provisioned using the Amazon EC2 plugin. The slaves have an IAM Instance Role which give the instance (virtual machine) permission to execute certain actions, in this case, it's allowed to use the registry. AWS API SDKs and the CLI (which is installed on our slaves) can then infer the credentials they need to call Amazon APIs (credentials are a key and a secret key and the system uses a complex-ish HTTP request signing algorithm). To log in to a registry, normally, you use one of these API calls to request temporary credentials with which you can log in to the registry.
Currently, what I do in my workflow script is manually log in with a shell command:
def dockerLogin() {
sh "aws --region=eu-west-1 ecr get-login > DOCKER_LOGIN"
sh readFile("DOCKER_LOGIN")
}
The aws ecr get-login command returns a shell command which you can execute to log in to docker (It returns something like docker login -u AWS -p very-long-password-here -e none https://registry-endpoint-here).
get-login is a convenience function which outputs a shell command to execute, but there is another command get-credentials which outputs a JSON object containing the username, password and endpoint (the endpoint doesn't change). A longer version where we have the proper credentials could look something like this:
def dockerLogin() {
sh "aws --region=eu-west-1 ecr get-authorization-token > DOCKER_LOGIN"
def text = readFile("DOCKER_LOGIN")
def json = new JsonSlurper().parseText(text)
def authorizationData = json['authorizationData'][0]
def String token = authorizationData['authorizationToken']
def endpoint = authorizationData['proxyEndpoint']
def auth = new String(token.decodeBase64()).split(":", 2)
sh "/usr/bin/docker login -u ${auth[0]} -p ${auth[1]} -e none ${endpoint}"
}
Honestly, this workaround seems to work fine and for us at least there is no huge need for a "proper" way of logging in but in the back of my mind, I feel this could be done nicer.
Add Comment
[JIRA] (JENKINS-41248) Infinite loop / Stack overflow when using a setter in pipeline
Title: Message Title
Gijs Kunze created an issue
Jenkins / JENKINS-41248
Infinite loop / Stack overflow when using a setter in pipeline
Issue Type:
Bug
Assignee:
Unassigned
Components:
pipeline
Created:
2017/Jan/20 11:08 AM
Environment:
Tested on Jenkins 2.32.1 LTS and 2.21
Priority:
Major
Reporter:
Gijs Kunze
We ran into a weird problem where our pipeline jobs would hang and have to be hard killed. After debugging and reducing the code to create a minimal example that would cause the issue we discovered the issue was the fact we were using a class with a setter (crazy, I know). This simple script causes the Run to hang indefinitely:
class Foo {
private int a;
public void setA(int a) {
this.a = a;
}
}
Foo foo = new Foo();
foo.setA(10);
It hangs when calling `setA` and when you kill the job the logs show:
Jan 20, 2017 11:00:41 AM org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService reportProblem
WARNING: Unexpected exception in CPS VM thread: CpsFlowExecution[Owner[test/2:test #2]]
java.lang.StackOverflowError
at com.cloudbees.groovy.cps.impl.CallEnv.getExceptionHandler(CallEnv.java:95)
at com.cloudbees.groovy.cps.impl.ProxyEnv.getExceptionHandler(ProxyEnv.java:56)
[JIRA] (JENKINS-40150) Git operations fail after global lib is loaded
Title: Message Title Gijs Kunze created an issue Jenkins / JENKINS-40150 Git operations fail after global lib is loaded Issue Type: Bug Assignee: Kirill Merkushev Components: github-plugin, workflow-cps-global-lib-plugin Created: 2016/Dec/01 12:33 PM Environment: Jenkins 2.21 Labels: github pipeline Priority: Minor Reporter: Gijs Kunze We have a single global library defined loaded from github. When we're running longer-running builds, we set the status of the commit using the GitHubCommitStatusSetter step: step([$class: 'GitHubCommitStatusSetter', statusResultSource: [$class: 'ConditionalStatusResultSource', results: []]]) Say the library is called LIB and the project we're building (also on github) is APP, when the above step is executed it tries to set the commit status with the commit-hash from APP on the repository LIB, which then fails because the LIB doesn't have this commit hash.
[JIRA] (JENKINS-40150) Git operations fail after global lib is loaded
Title: Message Title
Gijs Kunze updated an issue
Jenkins / JENKINS-40150
Git operations fail after global lib is loaded
Change By:
Gijs Kunze
We have a single global library defined loaded from github. When we're running longer-running builds, we set the status of the commit using the GitHubCommitStatusSetter step:{code:java}step([$class: 'GitHubCommitStatusSetter', statusResultSource: [$class: 'ConditionalStatusResultSource', results: []]]){code}Say the library is called LIB and the project we're building (also on github) is APP, when the above step is executed it tries to set the commit status with the commit-hash from APP on the repository LIB, which then fails because the LIB doesn't have this commit hash.{ code noformat } org.jenkinsci.plugins.github.common.CombineErrorHandler$ErrorHandlingException: java.io.FileNotFoundException: {"message":"No commit found for SHA: 172fd52d6393fae44ee1d962dc26098846489e1e","documentation_url":"https://developer.github.com/v3/repos/statuses/"}{ /code noformat }I think I can around this by explicitly specifying the repository in the GitHubCommitStatusSetter but ideally that shouldn't be necessary.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
