I have a Git repository abc.git containing submodules in it. We have a Jenkins job that is used to build abc.git repository.
The Jenkins job uses the GitSCM plugin to check out the code and do the build. Below is the plugin configuration that is used in the job.
checkout([$class: 'GitSCM', changelog: true, branches: [[name: "*/${branch}"]],
extensions: [[$class: 'SubmoduleOption', disableSubmodules: false,
parentCredentials: false, recursiveSubmodules: true, reference: '',
trackingSubmodules: true]],
userRemoteConfigs:[[credentialsId: '',
url: "${componentUrl}"]]])
When I do a commit in the ABC repository that commit is reflected in the Jenkins build changelog set. But when I do a commit in the submodules the commit is not getting shown in the Jenkins build changelog set.
Please let me know if there is any other configuration that needs to be added to the plugin configuration to make this work.
Also, let me know if there is an alternative way to solve this if the plugin does not support it.
But when I do a commit in the submodules the commit is not getting shown in the Jenkins build changelog set.
Two possible reasons:
You did a commit in the submodule, but
did not push to the remote submodule
and/or did not commit as well in the parent repository (in order to record the new submodule root tree SHA1)
You would see in the Jenkins changelog set the parent repository commit SHA1, recording the change of the submodule.
You would not see the submodule internal commit.
Related
We use the following command to release the current version.
mvn release:prepare release:perform
This command creates a tag in git that lets us know in the future which commit corresponds to a given released artifact.
When we want to generate a snapshot only and push it to Nexus, we use the below command, which pushes a timestamped snapshot to Nexus.
mvn deploy
Is there a way to tell Maven to create a git tag with the same snapshot name or even the snapshot timestamp just like the release plugin does?
Can maven does following?
Clone a repository with branch (Release-1.0) using maven-scm-plugin to specified target directory.(target/additional)
Do not clean target directory and update pom.xml (clone same repository at same directory just change branch to Release-1.1). Can maven just Pull and checkout the local repository with branch Release-1.1.
Say:
Step 1: Using pom.xml clone a repository with branch Release-1.0
Step 2: Update pom.xml with same repository just different branch Release-1.1.
If, I use configuration (skipCheckoutIfExists) then Maven is not updating remote repository with changed branch i.e Release-1.1
If i don't use skipCheckoutIfExists, it just overrides the old remote repository.
Can anyone give me alternate solution for this issue?
I'm getting started with Artifactory and am getting confused by all the terminology. What I'm trying to accomplish is the following:
$ git clone https://github.com/apache/hbase.git
$ cd hbase
$ git checkout branch-1.2
$ mvn clean install -DskipTests assembly:single
I'd like the git clone of this upstream project to live in Artifactory along with the components that Maven is pulling down. Additionally the final product zip file that mvn builds, hbase-assembly/target/hbase-1.1.6-bin.tar.gz, I want to store that in Artifactory too so that we can use it downstream in several CI jobs.
Questions
Is this approach correct?
How do I accomplish this?
Artifactory provides you with the Remote Repository functionality which you can also use to proxy various VCS services although I fail to see the point in just storing a clone of a git repo in Artifactory -
The VCS remotes are mainly used for cases where you directly include source code that you don't need to influence in your own code (i.e you can't git push changes back into Artifactory - they will not be persisted in the upstream git repo).
If you're aiming to have your CI job clone a certain branch, run tests, build it and then deploy build artifacts back to artifactory, I would suggest configuring your job to clone the git repo (using git not Artifactory) and then deploying the build artifacts back to Artifactory for downstream jobs to use.
Artifactory provides very extensive integration with popular build servers through which you can achive what's discussed here, your build artifacts should go into a Maven repository and the downstream jobs should reference it with their own pom files - you can quickly setup any Maven client to work with Artifactory using the Set Me Up dialog.
I have this in my pom:
<scm>
<connection>scm:javasvn:http://url.com/repo/myProject/trunk</connection>
<developerConnection>scm:javasvn:http://url.com/repo/myProject/trunk</developerConnection>
<url>http://url.com/websvn/listing.php?repname=repo&path=/myProject/trunk</url>
</scm>
When I run:
mvn release:branch -DbranchName=myBranch
It creates successfully the branch here :
http://url.com/repo/myProject/branches/myBranch
But when I look into the pom.xml of this branch, the "scm" part remains the same as the trunk
<scm>
<connection>scm:javasvn:http://url.com/repo/myProject/trunk</connection>
<developerConnection>scm:javasvn:http://url.com/repo/myProject/trunk</developerConnection>
<url>http://url.com/websvn/listing.php?repname=repo&path=/myProject/trunk</url>
</scm>
Doc says:
Transform the SCM information in the POM to include the final
destination of the tag
Isn't the plugin supposed to replace "/trunk" by "/branches/myBranch"? Or are we supposed to do this manually?
The plugin replaces "trunk" by the "branches/myBranch" but don't switch your working copy. In the new created branch, viewing the remote pom.xml the scm info should have changed for that branch. maven:release fails if it cannot commit the changes.
r1643
[maven-release-plugin] prepare for next development iteration
---------------------
r1642
[maven-release-plugin] copy for branch a-project-1.0
---------------------
r1641
[maven-release-plugin] prepare branch a-project-1.0
---------------------
Is your svn log looking like this at the revision you created the branch?
In this example, r1641 changed the pom scm info from "trunk" to "branches/a-project-1.0".
r1642 copied the trunk to the branch, creating it.
r1643 changed the pom scm info from "branches/a-project-1.0" to "trunk" again so you remain at trunk in your working copy.
When I've used maven release and it failed, always has shown an error at the command line and left temporal files at my working copy that have to be deleted or cleaned with mvn --batch-mode release:clean.
Try changing your scm.url to "http://url.com/repo/myProject/trunk" instead of "http://url.com/websvn/listing.php?repname=repo&path=/myProject/trunk" (I don't think maven can change your current url parameter)
Then go again with: mvn --batch-mode -DbranchName="A_TEST" -Darguments="-DskipTests=true"
and check console errors, the svn log at the svn projects root folder, and also check for local working copy modifications.
If all should have been OK and it's not, check your maven runtime version. I've got some problems working with maven:release and maven 3.0.5 when releasing tags. I only use maven 3.1+ for branching/releasing automation purposes.
I replaced
scm:javasvn:http://...
with
scm:svn:http://...
And the transformation is done now.
I am trying to create a branch from a tag with maven but the developerConnection property is not updated. How do I do this through maven or editing the pom.xml file manually?
We use subversion for scm and maven for build/release. I want to create a branch from the latest tag (release). We will use the branch for maintenance of the code, including bug fixes, and continue developing on the trunk. (I know that discussion of developing on trunk versus on branch is involved, and I don't want to open that up.)
When I use release:branch to create the branch, the developerConnection property refers to the tag that I checked out of to create my working copy. I want it to point to the branch.
I checked out the latest tag. (foo-80.0.8)
From the command line in the working copy directory of that tag, I ran:
mvn release:branch -DbranchName=foo-80.0.8.1.x -DupdateWorkingCopyVersions=false
(The .1.x refers to the 1 st branch with x as a placeholder indicator for branch version.)
In the resulting pom.xml in the branch on the repository, the developerConnection property was set to
...Foo/tags/foo-80.0.8 (I omitted the beginning of the URL to prevent the automatic hyperlink.) I want it to be ...Foo/branches/foo-80.0.8.1.x
I tried again, but this time, I edited the pom.xml file, and changed developerConnection to ...Foo/branches/foo-80.0.8.1.x. After running mvn release:branch ..., developerConnection in the pom.xml file still pointed to the tag.
UPDATE:
I took #twomey1's suggestion. (Thanks!) Now developerConnection points to ...\tags\foo-80.0.8.1.x which is not the original tag (good), but that tag doesn't exist (bad). I checked out a fresh copy of the new branch, modified pom.xml to point to the branch, and committed the change. When I tried mvn release:prepare I got this error message:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.0-beta-7:prepare (default-cli) on
project foo: You don't have a SNAPSHOT project in the reactor projects list.
UPDATE:
#twomey1's comment about SNAPSHOT helped. Using -DupdateVersionsToSnapshot on the command line, I got release:prepare to go forward but there still seems to be confusion with tags and branches. Again, my workflow:
Run svn checkout https:.../tags/foo-80.0.8.
Run mvn -DupdateVersionsToSnapshot=true -DupdateBranchVersions=true
-DupdateWorkingCopyVersions=false -DbranchName=foo-80.0.8.1 release:branch from the working copy of the tag that was just checked out.
Run svn checkout https:.../branches/foo-80.0.8.1 from the parent directory of the working copy.
Run mvn release:prepare from the working copy of the branch that was just checked out.
Then I get a svn error passed from maven that tag foo-80.0.8.1 already exists. I want to create a release from the branch which should not conflict. The developerConnection property still points to ...\tags\foo-80.0.8.1 which doesn't exist.
UPDATE:
I repeated with this difference, I added .1 to the end of the release version, the SCM release tag, and the portion of the development version before SNAPSHOT. This seems to work. I did this during mvn release:prepare.
From the official release plugin documentation
By default, the POM in the new branch keeps the same version as the
local working copy, and the local POM is incremented to the next
revision. If you want to update versions in the new branch and not in
the working copy, run:
mvn release:branch -DbranchName=my-branch -DupdateBranchVersions=true
-DupdateWorkingCopyVersions=false
Note: This can be useful if you want to create a branch from a tag
http://maven.apache.org/maven-release/maven-release-plugin/examples/branch.html
I think you are just missing -updateBranchVersions=true from your command