Is it possible to pass data generated by the script executed in the 'Execute shell' build step and insert it into the email report. I'm using the email-ext plugin and a Jelly template.
Use EnvInject plugin to propagate your variables "to the outside". Here is how you can do it.
I use groovy-based email template. See below what I've found. Maybe it will be helpful in Jelly templates as well:
<%
import hudson.model.*
def YOUR_VARIABLE= build.getEnvVars()["SOME_BUILD_PARAMETER"];
%>
Then you can use
${YOUR_VARIABLE}
Related
Instead of reading data out of 2sxc, I want to pump a list of data into a 2sxc stream. As all should run on the server-side within a razor script, I don't want to use WebApi and post every single entity.
It is possible to do CRUD operations within a razor script? Any example/demo available?
I found the page, which might interest you (official GitHub of 2sxc):
https://github.com/2sic/2sxc/wiki/razor-dnn
Finally I found it in the documentation:
App.Data.Create(contentTypeName, values, userName)
App.Data.Update(entityId, values, userName)
App.Data.Delete(entityId, userName)
https://2sxc.org/en/docs/Feature/feature/3360
https://github.com/2sic/2sxc/wiki/razor-app
I see it is possible in the docs but can't seem to find a way of implementing it.
Log API is also available via global PrimeFaces object in case you’d
like to use the log component to display your logs.
Using Primefaces 6.2
Primefaces Log Component
Binding Log4J to <p:log id="log" />
Everything in #Kukeltje's answer is true.
Still, if your end-game is to see your server logs in the front-end of your JSF app, I would do the following:
Add a DB appender to your logging framework so that all logs are written to the database.
https://logging.apache.org/log4j/2.x/manual/appenders.html#JDBCAppender
https://logback.qos.ch/manual/appenders.html#DBAppender
Create a jsf datatable to view the logs in. https://www.primefaces.org/showcase/ui/data/datatable/basic.xhtml
Initially, I would recommend that you filter the logs when retrieving it from the DB to only show the newest ones in the table, otherwise the table might be too big to load within a reasonable time. As a permanent solution, I would recommend that you implement the LazyDataModel
https://www.primefaces.org/showcase/ui/data/datatable/lazy.xhtml
It can be very handy to be able to filter and /or sort by log severity, time, and all the fields supported by by your logging framework.
Non related: Splunk has a universal forwarder utility that can submit a copy of your logs to a splunk server so that you can analyze your logs in near realtime. https://www.splunk.com/en_us/download/universal-forwarder.html
hope it is not too late.
I figured it out. From your Java Bean, you can use the PrimeFaces obj to execute a javascript in that way you can use for example the Primefaces.info('your log message'); to print in your log.
example function:
public void sendMessageToLog(int count) {
String text = "PrimeFaces.info('Testing Logger #" + count + "');";
PrimeFaces pf = PrimeFaces.current();
pf.executeScript(text); // This will execute the script in your page
}
PROBLEM
Let's say I have a jenkins/hudson job (for example free-style) that takes two parameters PARAM_ONE and PARAM_TWO. Now, I do not know the values of those parameters, but I can run some script (perl/shell) to find values of those parameters and then I want the user to select from a dropdown list after which I can start the build.
Is there any way of doing that?
Sounds like you've found a plug-in that does what you need, that is pretty similar to the built-in Parameterized Builds functionality.
To answer your second question: when you define parameterized builds, the parameters are typically passed to your job as environment variables. So you'd access them however you access environment variables in your language, for instance, if you defined a parameter PARAM_ONE, you'd access it as:
In bash:
$PARAM_ONE
In Windows batch:
%PARAM_ONE%
In Python:
import os
os.getenv('PARAM_ONE')
etc.
I imagine this would be the same for the Extended Choice Parameter plugin you are using.
Just install this, and give the parameter in the build script like:
Windows
"your build script" %PARAMONE% %PARAMTWO%
In Java, you can access these parameters off the run object
EnvVars envVars = new EnvVars();
envVars = run.getEnvironment(listener);
for (String envName2 : envVars.keySet()) {
listener.getLogger().println(envName2 + " = " + envVars.get(envName2));
}
I have to replace the standard mod_roster with my own custom roster. I wrote the module and see that it loads because it's start function is called by no other functions are called.
I also tried putting log output in all the methods of the standard mod_roster but I can't see any methods called which I log in using the Adium client.
Has anyone configured a custom roster module in ejabberd? Any ideas what I am doing wrong?
Look for {mod_roster, []}, in the ejabberd.cfg file and replace mode_roster with your module.
I installed the SetEnv plugin and it works fine for getting the variables during a task.
unfortunately when i try to use the env variable in the resulting status email I have no luck at all. Is this supposed to work?
I've tried both $VARNAME and ${VARNAME} - neither of which get replaced correctly in the email.
The simplest way to use environment variables (or any variables) in your email notifications is by using the Email-ext plugin.
Check their "Content token reference" for specifics but in short you get much more sophisticated substitution. Heres a few I use regularly:
${ENV, var} - Displays an environment
variable.
${BUILD_LOG_REGEX, regex, linesBefore, linesAfter, maxMatches, showTruncatedLines} - Displays lines from the build log that match the regular expression.
${CHANGES_SINCE_LAST_SUCCESS, reverse, format, showPaths, changesFormat, pathFormat} - Displays the changes since the last successful build.
${FAILED_TESTS} - Displays failing unit test information, if any tests have failed.
The plugin makes it easy to define a base "global" template in the Hudson configuration then sort of "extend" that template in your job configuration- adding additional detail. It also allows you to route notifications more granularly based on the build status/outcome.
This is possible already. It looks like you're using the wrong syntax. As mentioned previously, the email-ext plugin has a specific method for accessing environment variables. Try putting this in the email body instead:
${ENV, var=VARNAME}
An alternative method would be to use Hudson's execute shell feature to echo the environment variable during the build and parsing for it using BUILD_LOG_REGEX.
For example, you could have this in the Execute Shell part:
echo "Output: ${VARNAME}"
and parse it in the email using
${BUILD_LOG_REGEX, regex="^Output:", showTruncatedLines=false, substText=""}
It looks like I will have to wait for this:
http://wiki.hudson-ci.org/display/HUDSON/The+new+EMailer