I'd like to scan the build log at the end of each Teamcity build to count the number of deprecation warnings in the build. I don't want this to be a failure condition regardless of how many there are. I'd like to make this number a Teamcity statistic so that I can track it over time.
I'm pretty sure there are ways I could achieve this but they quickly become very hacky. I was hoping Teamcity would provide an option to build a statistic from running grep -c whatever over the build log but I can't find anything similar.
Is there an option for analyzing the build log to collect Teamcity build statistics?
I don't believe there is. You can create a TeamCity plugin to do what you need.
My solution was to add a build step that counts deprecation warinings in the app's log (not the Teamcity build log) and print a teamcity formatted message.
grep -c "DEPRECATION" %system.teamcity.build.checkoutDir%/log/app.log | xargs -I{} echo "##teamcity[buildStatisticValue key='deprecationCount' value='{}']"
Related
I am using TeamCity build server for my CI process. I have a scenario, where i need to compare my previous and current build log and check for warnings in the code ad if the warnings count in the current is greater than the previous build, we have to fail the build.
I have two build steps namely:
For MS build
A powershell script to compare the builds ( previous build and current build)
I understand we can get the build information using the TeamCity API which is http:// /httpAuth/downloadBuildLog.html?BuildId=<< current build id >>
Is there anyway to get the build log while the build is in running state, and pass on to my second step ?
Teamcity build log prints one or several symbols per each line.
I get the following output while build is running:
It is quite hard to read such output. Is there any way to force Teamcity print log for the entire length of the lines?
UPDATE: Our team found out that build log was affected by maven-surfire-plugin which was added to pom.xml. As we don't need this plugin for our current needs it was enough to remove it for resolving the problem.
I'm investigating a Maven/Jenkins/Artifactory set up as a possible solution for a CI/Release process.
I have a job in Jenkins - call it MYJOB - that builds and deploys an artifact to Artifactory. Now, I want another job that I can run manually that will copy the artifact of a particular build of MYJOB from Artifactory and put it somewhere (not too bothered where right now, but eventually it'll be another server).
For example, let's say build #123 went green, and now my QA team want to deploy the built artifact to their environment for further testing (the idea being to keep this artifact intact and unchanged throughout the testing process, before marking it as releasable). I want them to be able to enter '123' into Jenkins as a job parameter and then kick off the build.
So, I figure I need a free-style job that uses a script to do this.
My question is: How can I pass the number of a previous MYJOB build to the job, so that it will get the correct artifact from artifactory?
Alternative methods of achieving my goal are welcomed :)
So I got it working. I put the following code in the Build Step section of a Jenkins Freestyle Build Configuration after defining a parameter called 'REQ_BUILD_NUMBER':
SOMETHING=$(curl "http://MYARTIFACTORYLOCATION/artifactory/api/search/prop?build.number=$REQ_BUILD_NUMBER" | jq --raw-output '.results[0].uri')
echo $SOMETHING
SOMETHING_ELSE=$(curl $SOMETHING | jq --raw-output '.downloadUri')
echo $SOMETHING_ELSE
wget -N --directory-prefix=/var/lib/jenkins/artifacts/ $SOMETHING_ELSE
(NB: I'm barely competent at shell scripting. I'm sure it can be done in a better way)
EDIT: This requires installing 'jq' for the command line.
Create a Parameterized build for the second job. The QA team can put the build number when they start the build. This build number will be available as an environment variable which can be accessed in the scripts which can then retrieve the packages from the repository.
I have a script on Jenkins CI which optionally does dependency:go-offline. The other option should be to do nothing. But I can't put "" in there - it must be a goal.
So - which one would you pick? It should:
Be in central, always reachable
Take minimum time
Have minimal output
Have no side effects
I was thinking of some help:... goal but those tend to have a lot of output. Any better?
You can use this goal and option:
mvn --quiet help:help
the -q,--quiet option causes the output to only show errors.
Note that Jenkins allows you to add options like --quiet as diplayed in the usage: mvn [options] [<goal(s)>]. You configure these in the Jenkins job’s “Goals and options” field.
Check mvn --help output for further information.
I know this is an old question, but I came across it when I had the same requirement and it's still unanswered, so I'm posting for anyone who needs it in future.
This still depends on the current project, but could be useful if you don't want to hardcode a specific plugin for some reason:
mvn -pl ./ validate
-pl ./ means only current project, ignore submodules. Alternatively you could specify specific project by relative path or [groupId]:artifactId.
validate is the first phase of the Default Lifecycle. Doesn't change or build anything.
Alternatively, if you don't have a maven project at all, some maven plugins, or rather specific plugin goals, can be executed without it. E.g.:
mvn org.apache.maven.plugins:maven-dependency-plugin:2.1:help
It would still scan projects if it sees a POM in the current directory. And of course you still need to have the plugin in your local repository.
Maven spews out far too many lines of output to my taste (I like the Unix way: no news is good news).
I want to get rid of all [INFO] lines, but I couldn't find any mention of an argument or config settings that controls the verbosity of Maven.
Is there no LOG4J-like way to set the log level?
You can try the -q switch.
-q,--quiet Quiet output - only show errors
-q as said above is what you need. An alternative could be:
-B,--batch-mode
Run in non-interactive (batch) mode
Batch mode is essential if you need to run Maven in a non-interactive, continuous integration environment. When running in non-interactive mode, Maven will never stop to accept input from the user. Instead, it will use sensible default values when it requires input.
And will also reduce the output messages more or less to the essentials.
My problem is that -q is too quiet. I'm running maven under CI
With Maven 3.6.1 (April 2019), you now have an option to suppress the transfer progress when downloading/uploading in interactive mode.
mvn --no-transfer-progress ....
or in short:
mvn -ntp ... ....
That is what Ray proposed in the comments with MNG-6605 and PR 239.
Official link :
https://maven.apache.org/maven-logging.html
You can add in the JVM parameters :
-Dorg.slf4j.simpleLogger.defaultLogLevel=WARN
Beware of UPPERCASE.
Use the -q or --quiet command-line options
If you only want to get rid of the [INFO] messages you also could do:
mvn ... | fgrep -v "[INFO]"
To suppress all outputs (except errors) you could redirect stdout to /dev/null with:
mvn ... 1>/dev/null
(This only works if you use bash (or similar shells) to run the Maven commands.)
The existing answer help you filter based on the log-level using --quiet. I found that many INFO messages are useful for debugging, however the downloading artifact log messages such as the following were noisy and not helpful.
Downloading: http://nexus:8081/nexus/content/groups/public/org/apache/maven/plugins/maven-compiler-plugin/maven-metadata.xml
I found this solution:
https://blogs.itemis.com/en/in-a-nutshell-removing-artifact-messages-from-maven-log-output
mvn clean install -B -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn
Maven 3.1.x uses SLF4j for logging, you can find instructions how to configure it at https://maven.apache.org/maven-logging.html
In short: Either modify ${MAVEN_HOME}/conf/logging/simplelogger.properties, or set the same properties via the MAVEN_OPTS environment variable.
For example: setting MAVEN_OPTS to -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn configures the logging of the batch mode transfer listener, and -Dorg.slf4j.simpleLogger.defaultLogLevel=warn sets the default log level.