All the examples on plugins consist of a line like so:
cordova plugin add https://git-wip-us.apache.org/repos/asf/cordova-plugin-network-information.git
Where there is some git repo that has plugin.xml in its root.
Can I have a repo set up to contain two plugins in separate sub folders and how would the command line look to add those plugins.
And/or can I specify which branch from git to pull in?
Related
Within a Jenkins-Groovy pipelines I want to do the following:
Clone a particular GitLab based Code repo.
Then within this repo I want to find out all the files where there is a particular string. Example: "find_me"
Once found I want to change all these files from find_me to found_me.
Then commit these changes to the GitLab repo.
Step 4 above maybe I can find out myself, but I am struggling on how to do the 2nd and 3rd steps mentioned above.
Can anyone please suggest what can be the best way to do this?
Pipeline: SCM Step
findFiles: Find files in the workspace
readFile: Read file from workspace, writeFile: Write file to workspace, prependToFile: Create a file (if not already exist) in the workspace, and prepend given content to that file.
You can't commit to a GitLab repo directly from within Jenkins. You add/commit/merge locally, then you push. See, for instance: Is it possible to Git merge / push using Jenkins pipeline.
I can't find anything in the docs on how to do this - anybody have any ideas?
It seems it is currently not possible. But you can easily init a local git repository and use it as SCM without any remote hostings.
To init a git repo use the following commands in the root directory of your shared library (for example C:\Users\Jenkins\pipeline-shared-library-test):
git init
git add .
git commit -m "init"
Then in Manage Jenkins->Configure System->Global Pipeline Libraries you can point Project Repository to you local repo using a file URI file:///c:/Users/Jenkins/pipeline-shared-library-test
This approach works fine for me.
You can use File System SCM plugin to load your library from file system.
Once you have installed this plugin, use "Legacy SCM" in your library configuration to set a path and choose "master" as default version. Can not use Load implicitly, so explicit configuration should be done in the pipeline.
As a reference, I read this approach in this slides https://www.slideshare.net/roidelapluie/jenkins-shared-libraries-workshop.
I am testing the jenkins job-dsl plugin. I have an existing project where the setting 'Delete workspace before build starts' is enabled.
I have the following DSL defined:
job("$basePath/my-project") {
scm {
git {
remote {
name('origin')
url('git#bitbucket.org:my-organisation/my-project.git')
}
branch('*/develop')
extensions {
wipeOutWorkspace()
submoduleOptions {
recursive()
}
}
}
}
}
It seems this gives a configuration that is not really the same, it shows a "Wipe out repository & force clone" option. Are these options really the same thing in the end or are there different behaviours?
There is in general no difference between both options.
They are provided by different plugins:
Wipe out repository & force clone is part of the Git Plugin and only suitable as extension of the git plugin
Delete workspace before build starts is part of the Workspace Clean Plugin
The main differences between the Workspace Clean Plugin and the Git Plugin:
Not bound to Git SCM only
Allows the usage of ant file pattern to delete only some files or directories
An important behavior of the Git plugin's "Wipe out repository & force clone" option is that it will delete only the repository subdirectory if you have selected one in the "Check out to a subdirectory" option. It will leave the rest of your workspace alone. This doesn't appear in the documentation as far as I can tell.
You can achieve similar behavior with the Workspace Cleanup plugin by specifying the clone subdirectory in the "Pattern for files to be deleted" Advanced configuration section.
The end result is exactly the same, but in my observations the Git plugin deletion was 5 seconds faster than the Workspace Cleanup plugin.
If I want to use a plugin for Grails from Git Hub. Do I just download the zip file and make it available in my local maven repository? I'm behind a firewall which doesn't let me just resolve the dependencies.
You can get the source and run maven-install to make it available in your local maven repository, then you declare the dependency in the plugins block of the BuildConfig.groovy.
You shouldn't build from the repo source since that might include unfinished features and bugs. At the very least use source tagged for a particular release (if there are any).
If you want to download released plugins, they're available at http://repo.grails.org/grails/plugins/org/grails/plugins/
Keep in mind that running grails install-plugin /path/to/zip no longer works in 2.3, so you should stay away from that approach. Instead, you could run a local Artifactory instance that acts as a cached plugin repo - see this thread for some information to get started: http://grails.1312388.n4.nabble.com/Caching-plugins-using-artifactory-td4640164.html
The zip file which will be downloaded will be the source of the plugin. You have to extract the zip, go to the root of the plugin, and run grails maven-install (from release plugin) which would build the plugin artifact for you in you local maven repository if you have one setup.
Then you can use the plugin.
OR
You can use the plugin inline as mentioned in this answer.
Proxy setting can also be configured in grails by add proxy and set proxy.
grails add-proxy myproxy "--host=myproxy" "--port=myport" "--username=proxyuser" "--password=mypassword"
grails set-proxy myproxy
see grails docs.
if above solution doesn't work try then
create ProxySettings.groovy in C:\Documents and Settings\user-name.grails folder
add following two lines to this file and save
myproxy=["http.proxyHost":"myproxy", "http.proxyPort":"4300", "http.proxyUserName":"proxyuser", "http.proxyPassword":"mypassword"]
currentProxy="myproxy"
please check this link for more options
You can also keep plugins locally as described here
http://blog.armbruster-it.de/2011/10/project-setup-for-grails-with-customized-plugins-using-git-submodules/
git submodule add git://github.com/sarmbruster/grails-spring-security-ui.git plugins/grails-spring-security-ui
git add .gitmodules plugins/
git commit -m "added submodule"
now add plugins/grails-spring-security-ui as a inline plugin by adding to grails-app/conf/BuildConfig.groovy
grails.plugin.location.'spring-security-ui'="plugins/grails-spring-security-ui"
That's all.
More info in section "Installing Local Plugins" and "Specifying Plugin Locations" in docs:
http://grails.org/doc/latest/guide/plugins.html#12.1%20Creating%20and%20Installing%20Plug-ins
I have no experience with maven, so excuse me if this question is silly...
From another question (How does Grails handle plugin dependencies), I've learned that I can avoid the jar-hell in grails through maven repositories. But I now have the requirements that...
I am not allowed to use remote maven repositories
I would like to bundle the needed jars with my plugin (but low priority)
I would like to avoid the effort to install a local maven repository
I already worked with a reference to a local folder for plugin resolution. This works great.
But how do I have to structure a local folder in order to use this option:
repositories {
flatDir name:'myRepo', dirs:'/path/to/repo'
}
I mean, I could just drop the jar files to this folder, but how do I then reference those jar files? Do they have a naming schema like artifact_version.jar? Or do I have to create an XML configuration for this local repository?
Or is the effort to use a local maven repo small and maven is even already on my machine through grails?
The fact is Maven comes already with a local repository (~/.m2 on linux boxes). If you don't have access to an external repo, you just have to install your jars in the local repo, with this command
mvn install:install-file -Dfile=<path-to-file> -DgroupId=<group-id> -DartifactId=<artifact-id> -Dversion=<version> -Dpackaging=<packaging>
is 'jar' (without quotes) and group-id and artifact-id are either determined if it's 3rd-party library (go make a search on mvnrepository.com if you don't know them for a particular library) or you put there your group and artifact ids
EDIT : In fact, the naming scheme under the repository is for the library example version 1.2 from jexample.com is usually com/jexample/example/1.2/example-1.2.jar (groupId : com.jexample, artifactId : example, version : 1.0)