Context: I'm currently working on a research tool which needs to mine on Travis API to get information on builds from thousands of projects on Github. I want to find the best way to recognize if the projects are using Maven or Gradle as building tool.
I retrieve logs from Travis Builds and parse them, for now I'm using the following pattern for maven:
^(-------------------------------------------------------|\[INFO\] Reactor Summary:)$
and this one for gradle:
^(:[\w-]+)?:test[\w-]*$
Problem is I found everyday new projects that do not fit those regexp: then do you have any idea to improve them to spot a maximum of projects without false positive?
Edit: I'm mostly interested in projects which launch tests, that's why I started with those regexp.
This might be useful to you... a project which switched from maven to gradle
tader building with maven
tader building with gradle
Perhaps you could have a regex that says
If "mvn" appears in the logs before "gradle" or "gradlew" then it's a maven project
If "gradle" or "gradlew" appears before "mvn" then it's a gradle project
Related
I am learning AWS code pipeline and code build, I have a project(Angular App) where I am building and deploying it. But I also have a testing script that I was to run at a different stage.
I am doing testing using Karma and Jasmine.
The structure/stages I want is.
Source
Test //This is what I want to have
Build
Deploy
Question is, how do I do that? I have buildspec.yml file in the code build project, but that is oriented towards building the project and not testing it, so do I create a new code build project just to test it?
It would be amazing if I could use another buildspec.yml just for testing.
Anyone who is also running testing pipelines, help me out.
I'm writing my only build scripts and setup jenkins, Jenkins provide plugins to zip the build results, meanwhile I can zip the result in my own build scripts and call that scripts from Jenkins. Which way is better?
If you are in a corporate environment where a number of teams share the same Jenkins master, each plugin you add increases the probability of a plugin failure as and when you upgrade Jenkins. In addition, a bad plugin can bring down your entire CI server. So, in a common master scenario, be very conservative on adding plugins, don't add a plugin unless it is absolutely necessary. For something as simple as creating zips, any build tool worth its salt has a task that can zip contents in a given folder. Read through Maven and Gradle for a start.
We use maven to deploy the code changes to cq interner server / CRX Lite and the problem here is that it takes long time where the changes itself is often only one line code.
Has somebody experience with CQ5 with jetty and can give me a good Guide?
am not sure i understand the relationship with jetty (which ships as servlet container of latter versions of AEM/CQ5), but will answer to the code deployment part:
deploying a full content package (full content) should be done using
maven-content-package plugin for smaller deployments of content,
when you can't use integrated dev environments like sling eclipse dev
tools, i'd suggest you use the excellent repo command that basically zips the current folder and deploy it. I'm using it as an external tool command of intellij and it's really fast.
finally, if the deployment you're referring to is osgi deployment, maven sling plugin can help you with that (will still compile/package the whole osgi bundle though)
I've been contributing to a project in which there's a fixed pom.xml, but I tend to modify project.clj, temporarily, for various purposes. Most of the time, Leiningen seems to ignore pom.xml, but lein install and lein deploy rewrite pom.xml. Is this necessary to Leiningen's functioning? If not, can I stop it? Haven't found anything about this in the online docs yet.
It's not a big problem, but I'd rather not deal with having to restore the official pom.xml in my project before doing a 'git commit', for example.
EDIT: I discovered a solution for my situation, which is to create a 'checkouts' directory with a link to the other project. This causes the other project to be pulled in, without creating a new jar. However, I'm still curious: Does Leiningen need to create pom.xml e.g. for lein install? Why? I'd like to understand the process.
I'm unsure of whether lein install can be run without generating a pom.xml.
The reason it generates a pom is that leiningen uses maven to grab all the dependencies. In fact, maven is able to get dependencies from clojars and leiningen uses it for the clojure dependencies as well as the java ones. Maven requires a pom.xml to specify repository locations and other configuration necessary to run javac (or any other build commands) in addition to a groupId and artifactId to deploy your library to a (potentially local) repository
Another possible workaround to your issue is to use changelists (specifically, if using tortoiseSVN, I'd use the ignore-on-commit changelist) to ignore your pom.xml in most situations commitwise. I believe this stackoverflow answer may assist you with how to do that in git.
I am currently researching using the TeamCity CI software for our comapanies CI automation needs but have had trouble finding information about using different build scripts with TeamCity. We have C++ projects that need to have build/test automation and we currently have licenses for TeamCity. I have looked into using scons for the build automation but havent been able to find much information about using a python build script with TeamCity. If anyone could provide information about this to a CI beginner would be much appreciated.
Thanks
We use TeamCity to run our acceptance test suite (which uses Robot Framework - done in python).
Getting it to run was as simple as wrapping the python call with a very simple NAnt script. It does 2 things:
Uses an exec task to run python with the script as an argument.
Gets the xml output from the build and transforms it into something teamcity can understand.
There are probably tasks to run python scripts directly with NAnt but we've not had to use them - it was pretty easy to get up and running. You could do the same sort of thing using Ant or whatever depending on what your platform was.