GithubHelp home page GithubHelp logo

jenkinsci / saltstack-plugin Goto Github PK

View Code? Open in Web Editor NEW

This project forked from mchugh19/jenkins-saltapi

32.0 108.0 27.0 1.89 MB

A quick and dirty jenkins plugin to speak to a saltstack server via the salt api

Home Page: https://plugins.jenkins.io/saltstack/

License: MIT License

Java 95.34% HTML 4.66%

saltstack-plugin's Introduction

Saltapi Plugin

Jenkins Plugin GitHub release Jenkins Plugin Installs

This plugin sends a SaltStack API message as a build step

Basic usage

Components

Installing this plugin contributes following:

  • Send a message to Salt API - Build step

There are a few options for how to run a salt job:

local

This is the standard way to run a salt command. If command returns quickly, the results will be returned. Otherwise, if the command is long running, jenkins will not wait. If you wish to have jenkins wait for a long running command to finish, check the "Wait for completion" checkbox.

Salt syntax: "salt -N nodegroup webservers state.sls apache test=True"

local_batch

Similar to the local operation, but allows for only running the command on a few minions at a time. Jenkins will always wait for all minions to return before finishing, so long running commands will always block the build until finished.

Salt syntax: "salt -b '25%' -N nodegroup webservers state.sls deploy.websites test=True"

subset

Also similar to the local operation, but allows for only running the command on a subset of the target match. Jenkins will always wait for all minions to return before finishing, so long running commands will always block the build until finished.

Salt syntax: salt --subset=4 '*' service.stop zabbix-agent

runner

This allows you to run salt-run commands. It was intended to be used to kick off salt orchestration jobs

Salt syntax: salt-run state.orchestrate orchestration.refresh-apache pillar='{"target":testserver1.domain.com}'

hook

This publishes a message to the salt event bus. Useful for integrating with reactors from Jenkins

Curl syntax: curl -sS localhost:8000/hook/jenkins/notify/slack \
    -H 'Content-type: application/json' \
    -d '{"message": "Build ran"}'

Pipeline

As of the 2.0 release, Jenkins pipeline is supported

import groovy.json.*

node() {
  saltresult = salt authtype: 'pam', clientInterface: local(arguments: '"ls -la"', blockbuild: true,
    function: 'cmd.run', jobPollTime: 16, target: '*', targettype: 'glob'),
    credentialsId: 'a3d814c2-84ed-4752-94a8-271791bb5375', servername: 'http://localhost:8000'
  def prettyJson = JsonOutput.prettyPrint(saltresult)
  println(prettyJson)
}

Declarative Pipeline

Declarative pipelines are supported and function with the blueocean pipeline editor. As of blueocean 1.3 the pipeline editor does not fully render the input fields and requires some adjustments.

Add a step "Send a message to the SaltAPI"

Servername http://master.local:8000
Authtype pam
ClientInterface ${local(arguments: '"sleep 3; ls -la"', blockbuild: true, function: 'cmd.run', jobPollTime: 6, target: '\*', targettype: 'glob')}
CredentialsId b5f40401-01b9-4b27-a4e8-8ae94bc90250
Checkboxes SaveFile

Add a second step "Run arbitrary Pipeline script" to print results 

env.WORKSPACE = pwd()
def output = readFile "${env.WORKSPACE}/saltOutput.json"
echo output

All together this will create a declarative pipeline Jenkinsfile that looks something like:

JenkinsFile

pipeline {
  agent {
    node {
      label 'agent1'
    }

  }
  stages {
    stage('saltcommand') {
      steps {
        salt(authtype: 'pam', clientInterface: local(arguments: '"sleep 3; ls -la"', blockbuild: true, function: 'cmd.run', jobPollTime: 6, target: '*', targettype: 'glob'), credentialsId: 'b5f40401-01b9-4b27-a4e8-8ae94bc90250', saveFile: true, servername: 'http://master.local:8000')
        script {
          env.WORKSPACE = pwd()
          def output = readFile "${env.WORKSPACE}/saltOutput.json"
          echo output
        }

      }
    }
  }
}

Configuration

Jenkins

Simply fill out the connection details on the build page.

If using the wait for long commands to finish option, then you may want to adjust either the poll interval or the minion timeout. The default for both options are set on in the Jenkins configuration page or the default can be overwritten from on the individual job.

  • poll interval - controls how often jenkins will check in with the saltapi during a long running job. This can be set to something short (like 5 seconds) if you have a job that completes somewhat quickly. If you have a job that you know will run for an hour, checking every 5 seconds is a bit too frequent.
  • minion timeout - If you have a job that should be run on multiple minions but only some minions return, the minion timeout will set how long to wait for the remaining minions to come back before assuming them offline and marking the build as a failure. This is helpful as without the timeout, the jenkins salt plugin will wait forever for the possibly non-existent minions to return.

Allow the user accessing the salt api to have permission to the necessary salt modules. Also grant access for the @runner returner.

external_auth:
  pam:
    jenkins:
      - test.*
      - pkg.*
      - cmd.*
      - state.*
      - '@runner'

This jenkins module was written to use SaltStack's cherrypy api and tornado (as of 3.0.0). You will need to add something like the following to your salt master's configuration

rest_cherrypy:
  port: 8000
  ssl_crt: /etc/pki/tls/certs/localhost.crt
  ssl_key: /etc/pki/tls/certs/localhost.key
  expire_responses: False

rest_timeout: 7200

Note: some long running jobs may require increasing the rest_timeout or setting the expire_responses options.

You can test if you can access the API with the following command (changing the user and password to the right values).

$ curl -sSk https://<salt-master>:8000/login \
    -H 'Accept: application/x-yaml' \
    -d username=jenkins \
    -d password=jenkins \
    -d eauth=pam

Which would give you something similar to the following output.

return:
  - eauth: pam
    expire: 1458563520.558709
    perms:
      - .*
      - test.*
      - pkg.*
      - cmd.*
      - state.*
      - '@runner'
    start: 1458520320.558709
    token: 634c66d581806e5e9dacefbdc721cba45b78f63c
    user: jenkins

Logging Configuration

To see what is sent/received from the salt-api create a jenkins logger:

Name: salt logs
Logger: com.waytta.saltstack
Log level: ALL

To see what http requests are being sent:

Name: http
Logger: sun.net.www.protocol.http.HttpURLConnection
log level: ALL

To get any output from http, you may also need to add a default FINEST Jenkins logger on /jenkins/log/levels

Changelog

  • For versions 3.2.1 and older, see the Wiki page

saltstack-plugin's People

Contributors

chrillux avatar daniel-beck avatar daniel-beck-bot avatar jglick avatar kinow avatar mchugh19 avatar spacanowski avatar ssouris avatar thetacoscott avatar troxor avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

saltstack-plugin's Issues

plugin doesn't detect a non zero exit status returned from minion cmd.run function

Salt detects this well:

root@master:~# salt minion cmd.run 'true 1'
minion:
root@master:~# echo $?
0
root@master:~# salt minion cmd.run 'false 1'
minion:
ERROR: Minions returned with non-zero exit code
root@master:~# echo $?
11
root@master:~#

The plugin doesn't detect the error and continues the job.
It would rock if plugin detects this situation and fails the job (or not ? config parameter ?)

Wait for completion / polling causes exception.

Just running test.ping on a single server.
When "Wait for completion" is checked, this results in error:

FailedConsole Output

Started by user zerthimon
Building in workspace /var/lib/jenkins/jobs/test_salt/workspace
Running jid: 20160216174545917660
Problem: test.ping  to https://salt:8000 for infra01*:
net.sf.json.JSONException: JSONObject["info"] is not a JSONArray.

{"Error": "java.io.IOException: Server returned HTTP response code: 401 for URL: https://salt:8000/jobs/20160216174545917660\n\tat sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1840)\n\tat sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)\n\tat sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)\n\tat com.waytta.Utils.getJSON(Utils.java:57)\n\tat com.waytta.SaltAPIBuilder.perform(SaltAPIBuilder.java:259)\n\tat hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)\n\tat hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:782)\n\tat hudson.model.Build$BuildExecution.build(Build.java:205)\n\tat hudson.model.Build$BuildExecution.doRun(Build.java:162)\n\tat hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)\n\tat hudson.model.Run.execute(Run.java:1738)\n\tat hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)\n\tat hudson.model.ResourceController.execute(ResourceController.java:98)\n\tat hudson.model.Executor.run(Executor.java:410)\n"}
Build step 'Send a message to Salt API' marked build as failure
Finished: FAILURE

Works perfectly when "Wait for completion" is unchecked.

[Feature Request] Return state data back in yaml

It would be awesome if the local, local_batch, and runner calls would actually request the data with

Accept: application/x-yaml

So that we get a similar data format as we do when making these calls from the commandline.

Thanks
Daniel

Feature: an option to suppress output

It'd be nice to have a configuration option and use it when I don't want to hog the job's log with the salt mine query (I have one big query that I process later in a groovy script).

The option Save output to environment variable Cause error

If the option Save output to environment variable is enabled and the output is too large an exception is thrown:
FATAL: command execution failed
java.io.IOException: error=7, Argument list too long
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.(UNIXProcess.java:247)
at java.lang.ProcessImpl.start(ProcessImpl.java:134)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
Caused: java.io.IOException: Cannot run program "/bin/sh" (in directory "/var/lib/jenkins/jobs/Qualicheck slim/workspace"): error=7, Argument list too long
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
at hudson.Proc$LocalProc.(Proc.java:245)
at hudson.Proc$LocalProc.(Proc.java:214)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:850)
at hudson.Launcher$ProcStarter.start(Launcher.java:384)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:109)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66)
at hudson.plugins.postbuildtask.PostbuildTask.perform(PostbuildTask.java:123)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:720)
at hudson.model.Build$BuildExecution.post2(Build.java:186)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:665)
at hudson.model.Run.execute(Run.java:1755)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:405)

Question: SALTBUILDOUTPUT string format

I'm querying salt-mine for some data that I want to process later in groovy script step.
The resulting string in SALTBUILDOUTPUT in not a JSON, but rather a map converted into a string (single quotes). The logged query result (in jenkins job log) is JSON encoded though (double quotes).
Is this different by design (log format: JSON, buildoutput variable: not JSON) ?
Currently, to convert the result to JSON, I'm doing:

def jsonified = envVarsMap["SALTBUILDOUTPUT"].replaceAll( /'/, '"' )

in groovy script step.

saltstack-plugin reports jobs as failure even though everything indicates a success

Just upgraded to 2.0.0 today and our runner jobs have started reporting failures even though everything looks fine. This is the messages we see:

Building on master in workspace /var/lib/jenkins/workspace/Upgrade Organizations
ERROR: One or more minion did not return code 0

As well as this at the very end:

    "retcode": 0
  }
}]
Build was aborted
Finished: ABORTED

Output

Hi,

Is it possible to get an output of changes and errors only?

Thanks!
ido

Feature: Support for credentials storage

It'd be amazing if this plugin would use jenkins creds storage, so a user would then just need to specify the cred, not the username/password in every salt step in every job.

The plugin could use a better error detection

When there is an error in SLS, (like jinja error) the status is still SUCCESS.

Response on state.sls deploy.states.rsync_static, "pillar={"pillar_entry_point": "deploy_server:project_configs:some-project:static", "project_name": "some-project"}" for roles:static_some-project:
[{
  "minion1": ["Rendering SLS 'base:deploy.states.rsync_static' failed: Jinja variable 'str object' has no attribute 'rsync_client_pwfile'"],
  "minion2": ["Rendering SLS 'base:deploy.states.rsync_static' failed: Jinja variable 'str object' has no attribute 'rsync_client_pwfile'"]
}]
Finished: SUCCESS

Can plugin handle errors as Jenkins Failures?

Hello, can you please clarify if this plugin is able to interpret salt states errors as Jenkins failures. I always get Success event when I do test.ping (no matter if the requested host really exists or not).

Let's consider the default Salt CLI:

~  sudo salt -C 'G@node_use:stable and G@node_type:runtime' test.ping
pv.stab.lint.ro:
    True
➜  ~  echo $?
0
➜  ~  sudo salt -C 'G@node_use:stablest and G@node_type:runtime' test.ping
No minions matched the target. No command was sent, no jid was assigned.
➜  ~  echo $?
2

The second action was erroneous and returned with non-zero code. Compare this to the output of Jenkins SaltStack plugin:

Started by user jenkins
[EnvInject] - Loading node environment variables.
Building on master in workspace /var/lib/jenkins/jobs/DEPLOY_cocaine_runtime/workspace
Sending JSON: [{"client":"local","tgt":"G@node_use:stable and G@node_type:runtime","expr_form":"compound","fun":"test.ping"}]
Response on test.ping  for G@node_use:stable and G@node_type:runtime:
{"return": [{"pv.stab.lint.ro": true}]}
Finished: SUCCESS

Started by user jenkins
[EnvInject] - Loading node environment variables.
Building on master in workspace /var/lib/jenkins/jobs/DEPLOY_cocaine_runtime/workspace
Sending JSON: [{"client":"local","tgt":"G@node_use:stablest and G@node_type:runtime","expr_form":"compound","fun":"test.ping"}]
Response on test.ping  for G@node_use:stablest and G@node_type:runtime:
{"return": [{}]}
Finished: SUCCESS

net.sf.json.JSONException: JSONObject["return"] is not a JSONArray.

This seems to be similar but not the same as in #36. This occurred when running the same job that caused #55. This job of ours unfortunately seem really fickle since upgrading to the 2.x branch of the plugin.

ERROR: Build step failed with exception
net.sf.json.JSONException: JSONObject["return"] is not a JSONArray.
at net.sf.json.JSONObject.getJSONArray(JSONObject.java:1986)
at com.waytta.SaltAPIBuilder.performRequest(SaltAPIBuilder.java:265)
at com.waytta.SaltAPIBuilder.perform(SaltAPIBuilder.java:201)
at com.waytta.SaltAPIBuilder.perform(SaltAPIBuilder.java:161)
at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:81)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
at hudson.model.Build$BuildExecution.build(Build.java:206)
at hudson.model.Build$BuildExecution.doRun(Build.java:163)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
at hudson.model.Run.execute(Run.java:1728)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:405)
Build step 'Send a message to Salt API' marked build as failure
Finished: FAILURE

Call hook api

As a salt api plugin user I should be able to call and arbitrary hook Uri with arbitrary key/values So that I can take advantage of hooks and reactor states in salt.

  • Key/value pairs should be JSON posts to the hook URI
  • Invocation should provide a configurable auth token parameter, if not defined login dance should happen. If login dance happens...token is optionally provided back to caller
  • Should be able to configure "eauth" parameter as global or invocation parameter

net.sf.json.JSONException: 'object' is an array. Use JSONArray instead

Hello... looks like the plugin is having problem to parse a list respond.

client inteface: runner
target: noused
function: manage.present

from jenkins log:

Sending JSON: [{"client":"runner","mods":"","tgt":"notused","expr_form":"list","fun":"manage.present"}]
Jul 29, 2016 1:40:45 PM FINE com.waytta.saltstack
Received response: [["minion1","minion2","salt"]]

Errors:

Started by user admin
Building in workspace /var/lib/jenkins/workspace/_pull_minion_list_
ERROR: Build step failed with exception
net.sf.json.JSONException: 'object' is an array. Use JSONArray instead
    at net.sf.json.JSONObject.fromObject(JSONObject.java:167)
    at net.sf.json.JSONObject.fromObject(JSONObject.java:132)
    at com.waytta.Utils.validateFunctionCall(Utils.java:151)
    at com.waytta.SaltAPIBuilder.perform(SaltAPIBuilder.java:378)
    at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
    at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
    at hudson.model.Build$BuildExecution.build(Build.java:205)
    at hudson.model.Build$BuildExecution.doRun(Build.java:162)
    at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
    at hudson.model.Run.execute(Run.java:1720)
    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
    at hudson.model.ResourceController.execute(ResourceController.java:98)
    at hudson.model.Executor.run(Executor.java:404)
Build step 'Send a message to Salt API' marked build as failure
Finished: FAILURE

Waiting for completion does not work when minions are not connected

Greetings friend! Interesting observation I made a moment ago. Doing a simple ping across all my minions when one of the minions is disconnected will make the job run forever. In this example, cache1 is disconnected:

saltmaster$ salt '*' test.ping
web1:
    True
web2:
    True
cache1:
    Minion did not return. [Not connected]

and the API job call will look something like:

Waiting for 3 minions
2 minions are done
Will check status every 10 seconds...

for eternity, even if cache1 is reconnected after a period of time. I could increase the poll time perhaps. Is there something that the Salt API returns that can be checked to say "wait for completion", but only for connected minions? Feel free to toss this in the "not a bug, it's a feature" category if you like, just wanted to gather a thought on this 👍

SALTBUILDOUTPUT

Hi,

I have created a second "execute shell" build step with "echo $SALTBUILDOUTPUT".
I get this output -

[SaltTest] $ /bin/sh -xe /tmp/hudson5707637232705926996.sh

  • echo

Can you please help?

Thanks!
Ido

minionTimeout should be global in Builds.java

the current logic for local client with wait for completion in Builds.java will caused :

when there are some minions already done,
and some are not, and they will run for much longer.

in this siuation, We will change the "minionTimeout" setting in jenkins global configuration, which we thought this is a global timeout to a larger value.

and we thought plugin will continue poll job status with the interval of poll time which we defined in job configuration.

and then job will failed due to minionTimeout reached.

but actually plugin will directly wait for minionTimeout when not all minions had be done.

so it will wait for long time to job complete, even it will not take so much time for every time.

java.lang.String cannot be cast to net.sf.json.JSONObject

I'm trying to run simple runner command, but it constantly fails. Unfortunately I can't debug it myself, because not enough debug information provided. When I run same task from command-line curl - it works ok.

Here is a curl log:

curl -sSk https://mysalt.domain.tld/salt/ -H "X-Auth-Token: 123456789ABCDEF...." -d "client=runner" -d "fun=fileserver.update"
{"return": [true]}

Here is a jenkins' failure log:

Building remotely on dsg-buildman-mac-00 (android ios mac) in workspace /Users/jenkins/workspace/RS-Server-Deploy
Sending JSON: [{"client":"runner","mods":"","tgt":"notused","expr_form":"glob","fun":"cmd.run","arg":["fileserver.update"]}]
ERROR: Build step failed with exception
java.lang.ClassCastException: java.lang.String cannot be cast to net.sf.json.JSONObject
    at com.waytta.Utils.validateFunctionCall(Utils.java:141)
    at com.waytta.SaltAPIBuilder.perform(SaltAPIBuilder.java:339)
    at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
    at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:782)
    at hudson.model.Build$BuildExecution.build(Build.java:205)
    at hudson.model.Build$BuildExecution.doRun(Build.java:162)
    at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
    at hudson.model.Run.execute(Run.java:1738)
    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
    at hudson.model.ResourceController.execute(ResourceController.java:98)
    at hudson.model.Executor.run(Executor.java:410)
Build step 'Send a message to Salt API' marked build as failure
Finished: FAILURE

fileserver.update

Hi,

Is it possible to run "salt-run fileserver.update"?

Thanks!
Ido

Jenkins pipeline compatibility

Greetings,
kudos for this great plugin. Any plans to support the pipeline architecture? Or any example usage out there, you can point me to?

It is clear that Jenkins will favor the pipeline arch so it's maybe something to consider for this plugin as well. I've also noticed that it's not listed in the plugin compatibility list. Thnx for the support!

Minion count is off by 1

A job targeted just one minion....

15:08:31 Running jid: 20160411150831551700
15:08:32 Waiting for 1 minions
15:08:32 2 minions are done
15:08:32 ERROR occurred !

Support https_proxy

Hi,

I just tried to use the plugin and according to tcpdump and the access.log of the proxy in front of the API it doesn't even connect to the API server. Not even the "Test connection" works.
servername: https://saltapi.office.blah.de:443

A Curl in a Shell buildstep in the same job works just fine:

[...]
[salt_api] $ /bin/sh -xe /tmp/hudson310140799158824452.sh
+ curl -kI https://saltapi.office.blah.de:443
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0   181    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 10 Nov 2016 09:00:29 GMT
Content-Type: application/json
Content-Length: 181
Connection: keep-alive
Access-Control-Expose-Headers: GET, POST
Vary: Accept-Encoding
Allow: GET, HEAD, POST
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Set-Cookie: session_id=6d2f14935544aa64d0cbe4e80230d26d4697ae8e; expires=Thu, 10 Nov 2016 19:00:29 GMT; Path=/
[...]

I can't give you any Jenkins logs since I don't know what the right logger would be. The only error I get in the Console Output is the followig:

Auth Error: net.sf.json.JSONException: JSONObject["return"] is not a JSONArray.

{"Error": "java.net.SocketTimeoutException: connect timed out
Build step 'Send a message to Salt API' marked build as failure
Finished: FAILURE

I made sure that our self-signed cert is in Javas keystore.

Jenkins Version: 2.19.2
Salt Plugin Version: 1.7.1

Any help would be much appreciated.

local batch broken ?

Same configuration, works for "local" but doesn't for "local batch".

17:02:52 Running in batch mode. Batch size: 1
17:02:52 ERROR: Build step failed with exception
17:02:52 net.sf.json.JSONException: JSONObject["return"] is not a JSONArray.
17:02:52 	at net.sf.json.JSONObject.getJSONArray(JSONObject.java:1986)
17:02:52 	at com.waytta.SaltAPIBuilder.performRequest(SaltAPIBuilder.java:268)
17:02:52 	at com.waytta.SaltAPIBuilder.perform(SaltAPIBuilder.java:204)
17:02:52 	at com.waytta.SaltAPIBuilder.perform(SaltAPIBuilder.java:164)
17:02:52 	at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:81)
17:02:52 	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
17:02:52 	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
17:02:52 	at hudson.model.Build$BuildExecution.build(Build.java:206)
17:02:52 	at hudson.model.Build$BuildExecution.doRun(Build.java:163)
17:02:52 	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
17:02:52 	at hudson.model.Run.execute(Run.java:1730)
17:02:52 	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
17:02:52 	at hudson.model.ResourceController.execute(ResourceController.java:97)
17:02:52 	at hudson.model.Executor.run(Executor.java:405)
17:02:52 Build step 'Send a message to Salt API' marked build as failure

Error parsing runner response.

I'm running runner's task filesystem.update, It completes OK, but it seems that plugin cannot parse it's response and marks build as failed.

Here is successful execution by curl:

D:\sources\android>curl -X POST https://mysalt.domain.tld/salt/ -H "X-Auth-Token: 12345" -H "Content-Type: application/json" -d "[{\"client\":\"runner\",\"mods\":\"\",\"tgt\":\"notused\",\"expr_form\":\"nodegroup\",\"fun\":\"fileserver.update\",\"arg\":[]}]"
{"return": [true]}

Here is failing log from jenkins:

Building remotely on dsg-buildman-mac-00 (android ios mac) in workspace /Users/jenkins/workspace/RS-Server-Deploy
Sending JSON: [{"client":"runner","mods":"","tgt":"notused","expr_form":"nodegroup","fun":"fileserver.update"}]
ERROR: Build step failed with exception
java.lang.ClassCastException: java.lang.Boolean cannot be cast to net.sf.json.JSONObject
    at com.waytta.Utils.validateFunctionCall(Utils.java:141)
    at com.waytta.SaltAPIBuilder.perform(SaltAPIBuilder.java:339)
    at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
    at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:782)
    at hudson.model.Build$BuildExecution.build(Build.java:205)
    at hudson.model.Build$BuildExecution.doRun(Build.java:162)
    at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
    at hudson.model.Run.execute(Run.java:1738)
    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
    at hudson.model.ResourceController.execute(ResourceController.java:98)
    at hudson.model.Executor.run(Executor.java:410)
Build step 'Send a message to Salt API' marked build as failure
Finished: FAILURE

Feature: Allow disabling SSL cert check when connecting to salt-api

Having a self-signed cert on salt-api causes java ssl error:

"Error": "javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

It'd be nice to have an option to talk to salt-apis without having to add CA certs to java cert store.

[BUG] KWArguments only passing one key:value pair

When using the following settings (omitting user/pass type settings):

Client Interface: local
Target: tldweb*
Target Type: glob
Function: state.sls
Arguments: containers.update-rnvapi
KWArguments: 'pillar={image: "reg-cn-document-rest-api", tag: "2.0.6-SNAPSHOT.b177", env: "test", volume: "/opt/registrar/certs:/certs:ro", name: "rnv-api"}'

It is failing to pass the paramaters. Here is what I am seeing from a salt-run state.event pretty=True:

salt/job/20151124224350138890/ret/SERVERNAMEHERE    {
    "_stamp": "2015-11-25T05:43:50.384232",
    "cmd": "_return",
    "fun": "saltutil.find_job",
    "fun_args": [
        "20151124224310032167"
    ],
    "id": "SERVERNAMEHERE",
    "jid": "20151124224350138890",
    "retcode": 0,
    "return": {
        "arg": [
            "containers.update-rnvapi",
            {
                "'pillar": "{image: reg-cn-document-rest-api",
                "__kwarg__": true
            }
        ],
        "fun": "state.sls",
        "jid": "20151124224310032167",
        "pid": 12272,
        "ret": "",
        "tgt": "tldweb1*",
        "tgt_type": "glob",
        "user": "jenkins"
    },
    "success": true
}

Running this via the jenkins should be the equivilant of the following:

salt '*tldweb1*' state.sls containers.update-rnvapi 'pillar={image: "reg-cn-document-rest-api", tag: "2.0.6-SNAPSHOT.b177", env: "test", volume: "/opt/registrar/certs:/certs:ro, name: "rnv-api"}'

I am able to successfully run this locally on the salt-master via the salt command above, or from anywhere via a curl request so it isn't an issue with the state or the master. I was wondering if some light could be shed on this?

Plugin fails with NPE when configured with a nonexistant variable

When there is a variable such as {{BADVARIABLE}} in configuration, that doesn't exist in the environment, the plugin fails with NPE:

ERROR: Build step failed with exception
java.lang.NullPointerException
    at java.lang.String.replace(String.java:2240)
    at com.waytta.Utils.paramorize(Utils.java:125)
    at com.waytta.SaltAPIBuilder.perform(SaltAPIBuilder.java:222)
    at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
    at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:782)
    at hudson.model.Build$BuildExecution.build(Build.java:205)
    at hudson.model.Build$BuildExecution.doRun(Build.java:162)
    at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
    at hudson.model.Run.execute(Run.java:1738)
    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
    at hudson.model.ResourceController.execute(ResourceController.java:98)
    at hudson.model.Executor.run(Executor.java:410)
Build step 'Send a message to Salt API' marked build as failure

This would be great if I could get a notification which variable failed to resolve. 'Cos this got me wondering what happened to the job and then took me some time to figure out which variable was mispelled and causing the error (i have several variables in the plugin config (salt role, pillar parameters, etc)

Plugin not allowing selection of credentials during creation

I am trying to create a new project in jenkins. It will simply call highstate. The build step is configured to use a user with ssh key set up via jenkins credentials. However in the credential selector box I only ever get none.
capture
It says 'cannot find any credentials with id'. I have verified the credentials are set up properly and it does work with the git plugin.

When targeting results in zero minions the plugin doesn't report any error

If there are no minions that could be targeted, the plugin returns with:

16:16:37 Response on test.ping  for zinfra*:
16:16:37 [{}]

And continues the run....

Salt detects this well:

root@infra01:/# salt zinfra\* test.ping
No minions matched the target. No command was sent, no jid was assigned.
ERROR: No return received
root@infra01:/# echo $?
2
root@infra01:/#

Is this another salt-api limitation ?

Job succesfully finishes in case if SLS can't be rendered

Hi, it's me again :)

I have noticed that plugin treats Jenkins job as successfully finished when target SLS file even couldn't be rendered...

Started by upstream project "DOCKER_IMAGE_centrifugo" build number 21
originally caused by:
 Started by upstream project "LOCAL_PROJECT_shilkin_centrifugo" build number 19
 originally caused by:
  Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on deployer (deploy) in workspace /var/lib/jenkins/workspace/DEPLOY_centrifugo
Sending JSON: [{"client":"local","tgt":"p-3-testmap.pio.tv.ro","expr_form":"glob","fun":"state.sls","arg":["mailpaas.centrifugo"]}]
Running jid: 20160510124113361338
Waiting for 1 minions
0 minions are done
Will check status every 10 seconds...
Response on state.sls mailpaas.centrifugo for p-3-testmap.pio.tv.ro:
[{
  "outputter": "highstate",
  "data": {"p-3-testmap.pio.tv.ro": ["Rendering SLS 'base:mailpaas.centrifugo' failed: mapping values are not allowed here; line 40\n\n---\n[...]\n    - ports: [{8001: 8001}]\n    - network_mode: host\n    - environment:\n      - SERVICE_NAME: centrifugo\n      - SERVICE_TAGS: testing\n    - command: --port=8001 --engine=tarantool --tt_aggr_node=testing.cocaine-agregate-node.service.consul --tt_aggr_port=10053 --tt_service_name={'subsystem': 'mail', 'binary': 'ttconnector', 'app': 'mailpaas-ttconnector', 'group': 'ttconnector'} --tt_acl=dummy_acl --tt_host=testing.tarantool-notification.service.consul --tt_port=33013 --tt_user=test --tt_password=123 --log_level=debug    <======================\n    - require:\n      - docker: centrifugo_image\n\u0000\n---"]}
}]
Finished: SUCCESS

Salt API returns TimeoutError on Jenkins Pipeline

Hi Everyone,

Has anyone here encountered these errors before?

`[Pipeline] // withCredentials
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Deployment)
[Pipeline] withCredentials
[Pipeline] {
[Pipeline] sh
[staging-server] Running shell script

  • curl -sS 10.10.214.233:8181/run -H Accept: application/x-yaml -d client=local -d tgt=minion.id -d fun=cmd.run -d arg=/bin/sh -e /home/user/scripts/deployment.sh -d username=**** -d password=**** -d eauth=pam
    Unrecoverable error in the server.
    Traceback (most recent call last):
    File "/usr/lib/python2.7/dist-packages/cherrypy/_cpwsgi.py", line 180, in trap
    return func(*args, **kwargs)
    File "/usr/lib/python2.7/dist-packages/cherrypy/_cpwsgi.py", line 99, in call
    return self.nextapp(environ, start_response)
    File "/usr/lib/python2.7/dist-packages/cherrypy/_cpwsgi.py", line 410, in tail
    return self.response_class(environ, start_response, self.cpapp)
    File "/usr/lib/python2.7/dist-packages/cherrypy/_cpwsgi.py", line 234, in init
    self.run()
    File "/usr/lib/python2.7/dist-packages/cherrypy/_cpwsgi.py", line 349, in run
    request.run(meth, path, qs, rproto, headers, rfile)
    File "/usr/lib/python2.7/dist-packages/cherrypy/_cprequest.py", line 617, in run
    raise cherrypy.TimeoutError()
    TimeoutError
  • echo 0
    0
    [Pipeline] }
    [Pipeline] // withCredentials
    [Pipeline] }
    [Pipeline] // stage
    [Pipeline] }
    [Pipeline] // node
    [Pipeline] End of Pipeline
    Finished: SUCCESS`

The script successfully executed on the minion server but failed to return the build log.

Jenkins version: 2.32.2
SaltStack plugin version: 2.0.1

Any thoughts?

Job succesfully finishes in case if SaltMinion was busy with another job

it's notorious that SaltStack is not designed for concurrent task execution, and if one job was started at the time when another one is already running, the first one will be failed. I suggest that Jenkins SaltMinion plugin should treat this situation correctly.

Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on deployer (deploy) in workspace /var/lib/jenkins/workspace/DEPLOY_tarantool_id
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url [email protected]:common/tarantool-schema.git # timeout=10
Fetching upstream changes from [email protected]:common/tarantool-schema.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress [email protected]:common/tarantool-schema.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 2e39f343a7c32987bc890fd1ec2fcfdd9b37d2af (refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 2e39f343a7c32987bc890fd1ec2fcfdd9b37d2af
 > git rev-list d0761fe60ff6e7bbf905da8fc017764bf4ccf611 # timeout=10
Sending JSON: [{"client":"local","tgt":"p-3-testmap.pio.tv.ro","expr_form":"glob","fun":"state.sls","arg":["mailpaas.tarantool.id"]}]
Running jid: 20160525143608909933
Waiting for 1 minions
2 minions are done
Response on state.sls mailpaas.tarantool.id for p-3-testmap.pio.tv.ro:
[{
  "outputter": "highstate",
  "data": {"p-3-testmap.pio.tv.ro": ["The function \"state.sls\" is running as PID 5055 and was started at 2016, May 25 14:36:08.806390 with jid 20160525143608806390"]}
}]
Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered
Triggering a new build of ROOT_DEPLOY
Finished: SUCCESS

[Feature Request]Supply an option to control whether executing 'run.setResult(Result.FAILURE)'

Currently, when salt command got an exception, 'saltstack-plugin' will set currentBuild.result to 'FAILURE':
SaltAPIBuilder.java:

try {
            success = perform(run, launcher, listener);
        } catch (SaltException e) {
            run.setResult(Result.FAILURE);
            throw new AbortException("Salt run failure: " + e);
        }
    	if (!success) {
    	    run.setResult(Result.FAILURE);
    	    throw new AbortException("Salt run failure");
    	}

Builds.java

                    if (timeoutFail) {
                        build.setResult(Result.FAILURE);
                        throw new SaltException(httpArray.getJSONObject(0).getJSONObject("Result").toString());
                    }

But, in my case, when I got an exception, I will also catch this exception, and then do something to make the pipeline pass; Meanwhile, I want to set 'currentBuild.result'='SUCCESS', but it's not workable due to Jenkins mechanism: 'the result can only get worse':

    public void setResult(@Nonnull Result r) {
        if (state != State.BUILDING) {
            throw new IllegalStateException("cannot change build result while in " + state);
        }

        // result can only get worse
        if (result==null || r.isWorseThan(result)) {
            result = r;
            LOGGER.log(FINE, this + " in " + getRootDir() + ": result is set to " + r, LOGGER.isLoggable(Level.FINER) ? new Exception() : null);
        }
    }

So, I want to request a feature that 'saltstack-plugin' could supply an option to control whether executing 'run.setResult(Result.FAILURE)'

Thanks very much!

Project status

Hi,

When I execute a command (for example - highstate) and the target servers are wrong, the build still finished as success.

Response on state.highstate for G@env:stage:

  • {}

Finished: SUCCESS

Please advise.
Thanks!
Ido

Plugin reports failure early but job continues

I started a job that takes quite some time to return (1,5h) however it returned after just a few minutes with the following:

Started by user John Doe
Building in workspace /var/lib/jenkins/workspace/Upgrade application
Problem with state.orchestrate  for not_used:
net.sf.json.JSONException: JSONObject["return"] is not a JSONArray.

{"Error": "java.io.IOException: Server returned HTTP response code: 500 for URL: https://salt-master.example.com:8000
Build step 'Send a message to Salt API' marked build as failure
Finished: FAILURE

How to pass more than 1 pillar variable ?

Do you know how to pass more than a single pillar value when using a runner (orchestration)?

salt-run state.orchestrate orch.orc_ddns-v2 pillar='{IPallocation: 1.2.3.4, hostname: mynewhost}'

Client interface: runner
mods: orch.orc_ddns-v2
Function: state.orchestrate

I tried multiple combinations in Arguments and KWArguments but nothing worked.
Using the Set Pillar Data looks like it only takes 1 entry.

Job succesfully finishes in case if Pillar can't be compiled

Hello!

I would suggest that the failure of SaltStack job caused by uncompilable Pillar should be unambiguously interpreted as an error on Jenkins.

Using 1.6.1 version of plugin I'm encountering this undesirable behaviour.

Started by user jenkins
[EnvInject] - Loading node environment variables.
Building remotely on deployer (deploy) in workspace /var/lib/jenkins/workspace/DEPLOY_postgresql_avatars_migrate
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url [email protected]:Database/avatars.git # timeout=10
Fetching upstream changes from [email protected]:Database/avatars.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress [email protected]:Database/avatars.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision cb7dcdff99f4620aaad431f8bc190dafe2b8755d (refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f cb7dcdff99f4620aaad431f8bc190dafe2b8755d
 > git rev-list cb7dcdff99f4620aaad431f8bc190dafe2b8755d # timeout=10
Sending JSON: [{"client":"local","tgt":"p-3-testmap.pio.tv.ro","expr_form":"glob","fun":"state.sls","arg":["mailpaas.postgresql.migrate.avatars"]}]
Response on state.sls mailpaas.postgresql.migrate.avatars for p-3-testmap.pio.tv.ro:
[{"p-3-testmap.pio.tv.ro": [
  "Pillar failed to render with the following messages:",
  "Rendering SLS 'nginx-frontend' failed, render error:\nJinja error: oauth2.sls\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/salt/utils/templates.py\", line 366, in render_jinja_tmpl\n    output = template.render(**decoded_context)\n  File \"/usr/lib/python2.7/dist-packages/jinja2/environment.py\", line 989, in render\n    return self.environment.handle_exception(exc_info, True)\n  File \"/usr/lib/python2.7/dist-packages/jinja2/environment.py\", line 754, in handle_exception\n    reraise(exc_type, exc_value, tb)\n  File \"<template>\", line 18, in top-level template code\n  File \"/usr/lib/python2.7/dist-packages/salt/utils/jinja.py\", line 144, in get_source\n    raise TemplateNotFound(template)\nTemplateNotFound: oauth2.sls\n\n; line 18\n\n---\n[...]\n{% set av = av_cfg.avatars %}\n\n{% import_yaml \"attachloader.sls\" as al_cfg %}\n{% set al = al_cfg.attachloader %}\n\n{% import_yaml \"oauth2.sls\" as oauth2_cfg %}    <======================\n{% set oauth2 = oauth2_cfg.oauth2 %}\n\n{% import_yaml \"raw-content-reader.sls\" as rcr_cfg %}\n{% set rcr = rcr_cfg[\"raw-content-reader\"] %}\n\n[...]\n---"
]}]
Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered
Triggering a new build of DEPLOY_cocaine_runtime
Finished: SUCCESS

Pleas consider this issue.

Possibility to use pillars for more than salt-runners

Would it be possible to have the functionality implemented in #15 available for local and local_batch as well?

EDIT: I'm currently trying to pass in pillars as KWarguments: pillar='{"data":{"organization": "{{ORGANIZATION_NAME}}", "jmx_enabled":"{{JMX_ENABLED}}","cluster":"{{CLUSTER_NAME}}","port_suffix":"{{PORT_SUFFIX}}","instance_hosts":"{{INSTANCE_HOSTS}}"}}'

Unfortunately that does not work and I'm met with:

Waiting for 1 minions
1 minions are done
Response on state.sls application.create-cluster for host.example.org:
[{"host.example.org": "ERROR executing 'state.sls': Pillar data must be formatted as a dictionary, unless pillar_enc is specified."}]
Finished: SUCCESS

EDIT2: This should probably not finish with SUCCESS

Only Global credentials are shown

In the Credentials drop-down I can only see those credentials which are on the global level. None of credentials for the folder are shown. To be sure I checked if I can see the folder credentials in the SCM part. I was able to select folder creds in the Git configuration.

Jenkins Version: 2.19.2
Salt Plugin Version: 1.7.1

Cheers

test=True kwarg fails to return output to build console log

I am trying to use the kwarg test=True to see the changes before I actually run them but it fails to return any output in the build logs. It gives the following error:

Started by user Tyler Hunt
[EnvInject] - Loading node environment variables.
Building in workspace /usr/share/tomcat7/.jenkins/jobs/A Salt the Server/workspace
ERROR: Build step failed with exception
net.sf.json.JSONException: JSONObject["result"] is not a Boolean.
    at net.sf.json.JSONObject.getBoolean(JSONObject.java:1929)
    at com.waytta.Utils.validateInnerJsonObject(Utils.java:208)
    at com.waytta.Utils.validateInnerJsonObject(Utils.java:215)
    at com.waytta.Utils.validateFunctionCall(Utils.java:178)
    at com.waytta.SaltAPIBuilder.perform(SaltAPIBuilder.java:377)
    at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
    at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:782)
    at hudson.model.Build$BuildExecution.build(Build.java:205)
    at hudson.model.Build$BuildExecution.doRun(Build.java:162)
    at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534)
    at hudson.model.Run.execute(Run.java:1738)
    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
    at hudson.model.ResourceController.execute(ResourceController.java:98)
    at hudson.model.Executor.run(Executor.java:410)
Build step 'Send a message to Salt API' marked build as failure
Notifying upstream projects of job completion
Finished: FAILURE

When I run it without specifying test=True then it works. It also works with any other arguments or kwargs. I tested with the following equivalent salt commands (translated from build params to what is passed into salt):

salt '*' test.arg 1 "two" 3.1
salt '*' test.arg txt="hello" wow='{a: 1, b: "hello"}'
salt '*' test.arg 1 "two" 3.1 txt="hello" wow='{a: 1, b: "hello"}'

These worked just fine. Some more tests resulted in interesting findings:

salt '*' state.sls docker mock=True test=True #worked fine
salt '*' state.sls docker test=True #resulted in the error

wait for completion always waits until timeout has been reached

It seems using the "Wait for completion" checkbox makes jobs wait until the set timeout. On the other hand not using "Wait for completion" seems to successfully wait for completion. Something seems to be a little bit off?

The console output below is from when "wait for completion" was turned on.

14:05:40 Running jid: 20170308130540775378
14:05:43 Waiting for 1 minions
14:05:43 0 minions are done
14:05:43 Will check status every 10 seconds...
14:05:55 Some minions returned. Waiting 600 seconds
14:15:57 Response on state.sls application.host-app pillar='{"data":{"app":"application-admin","version":""}}' for apps.dev.example.com:

Question: saveEnvVar for pipeline

Looking over the code I've noticed that you have a saveEnvVar variable for the salt pipeline step, but it doesn't appear to be used in the performRequest method.

Is there a reason this bit isn't there for a pipeline step? With the Jenkins pipeline declarative syntax saving the output per your example:

import groovy.json.*

node() {
  saltresult = salt authtype: 'pam', clientInterface: local(arguments: '"ls -la"', blockbuild: true,
    function: 'cmd.run', jobPollTime: 16, target: '*', targetType: 'glob'),
    credentialsId: 'a3d814c2-84ed-4752-94a8-271791bb5375', servername: 'http://localhost:8000'
  def prettyJson = JsonOutput.prettyPrint(saltresult)
  println(prettyJson)
}

result's in a syntax error, so it has to be wrapped in a script block like this:

stage('Deploy to Test A Side') {
    when { branch "master" }
    steps {
        echo 'Deploying to Test...'
        script {
            saltresult = salt authtype: 'pam', clientInterface: local(arguments: "ls -la", blockbuild: true, function: 'cmd.run', target: '*', targetType: 'glob'), credentialsId: 'a3d814c2-84ed-4752-94a8-271791bb5375', servername: 'http://localhost:8000'
            def prettyJson = JsonOutput.prettyPrint(saltresult)
            println(prettyJson)
        }
    }
    post {
        failure {
            error("Build failed due to failed salt run")
        }
    }
}

which, for the most part works for me, but I was curious if it'd be possible to save the output using the saveEnvVar option, or some other method. I've been looking for the last day or so on the best ways of saving that output in a pipeline, specifically for the declarative pipeline DSL stuff, but wanted to get your take on it in case you've already been down that rabbit hole.

Thanks

Please enable parameterized 'Pillar value'

I need to be able to use parameters in the 'Pillar value' field. For example let's say I have two parameters:
APPLICATION
VERSION

I would like to be able to do this:
Pillar value: {"application": "${APPLICATION}", "version": "${VERSION}"}

SaltAPI - Jenkins master/slave

Hi,

If I use "Restrict where this project can be run", is the connection to the SaltAPI server should be from the master of from the slave server?

Thanks!
Ido

"comment": "Unable to manage file: 'hash_type'",

Hello, we're using this plugin for deploying freshly built jar files to our dev servers and we're getting the error in the title in the Salt output.

"file_|-java-jar-file_|-/opt/project/api.jar_|-managed":     {
  "comment": "Unable to manage file: 'hash_type'",
  "pchanges": {},
  "name": "/opt/project/api.jar",
  "start_time": "10:48:47.280779",
  "result": false,
  "duration": 2972.47,
  "__run_num__": 9,
  "changes": {},
  "__id__": "java-jar-file"
 },

I wonder if this has anything to do with the fact that Salt statement has "skip_verify: True" in it and the plugin isn't parsing what it's sending to Salt properly as a result? See attached a redacted version of the config (is this the right way to pass a pillar?).
saltfail

And finally here is the Salt statement that java-app is running to push that file

java-jar-file:
  file.managed:
    - name: /opt/{{ pillar['java-app']['app-name'] }}/{{ pillar['java-app']['jar-name'] }}.jar
    - source: {{ pillar ['java-app']['autodeploy-url'] }}
    - skip_verify: True
    - user: java-app
    - group: java-app
    - listen_in:
      - service: {{ pillar['java-app']['app-name'] }}
    - require:
      - file: java-app-home
      - file: java-app-service
      - user: java-app
      - group: java-app

I'm fairly sure the issue is in the plugin, as I am able to successfully run the same statement by hand using curl so I think the API is configured properly.

Sadly Jenkins isn't my forte so please let me know if there's more information you need or more diagnostics I can get from Jenkins and/or the plugin.

Thanks

rest_tornado support

Just installed the v2.0-beta1.

It works like a charm when you run rest_cherrypy. However, when running rest_tornado, the login request is denied with

HTTP/1.1 400 Bad Request
Date: Fri, 18 Nov 2016 20:07:02 GMT
Content-Length: 73
Content-Type: text/html; charset=UTF-8
Server: TornadoServer/4.2.1

<html><title>400: Bad Request</title><body>400: Bad Request</body></html>

This might be a bug in rest_tornado - I'm not that sure about the api spec.

The rest_cherrypy webserver accepts the login credentials in the form

[
  {
    "username": "rootus_rootus",
    "password": "thebigsecret",
    "eauth": "auto"
  }
]

as well as

{
  "username": "rootus_rootus",
  "password": "thebigsecret",
  "eauth": "auto"
}

rest_tornado only accepts the latter

Btw - great kudos for the awesome plugin!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.