I'd like to be able to back up an existing artifact in a repo during the install phase?
Can I do this with maven?
Currently I am coding a xcopy in a bat file that calls mvn install, but I think there has to be a better way?
Additionally, is there a way for me to determine via maven or a windows command prompt the maven repository location?
To get current repository location you can use mvn help:effective-settings help command to print all settings.
As for archiving artifacts before install, it goes against Maven ideology. Basically snapshot versions can be overwritten at any time and release versions must never change. Instead of updating release version you need to change version (e.g. increase it).
Related
I have a Jenkins job that gets the code from version control and builds (like what a normal pipeline do), I was doing is that after building the project, I download the build and use FTP to transfer that build to the client's server then I unzip it and then copy the whole build because I copy whole build my application's down time is very high. (I have to use FTP because as a service provider we have some limitations and can't change this policy)
What I wanted to do is that Jenkins know what is changed when it is building so Jenkins will create a package with all the changes and with the correct path where the file should go, and I can download that package and copy that package and just run the package so whatever was changed only that should get updated.
Is that possible? Is there any plugin that I can use?
This really depends on the build tool/language you are using to build you application. I dont think there is a generic jenkins plugin.
Other idea would be to upload your package to a local Nexus server. Download after the next build and the compare the files from old and new build. With this information you can create a patch package for your clienst server.
Each time i generate my build through jenkins, my existing jar file in the target folder is overwritten by maven. For example: i have a existing version of 1.0 in jenkins target folder, now if i create a new build with version 1.1, the previous version in my target folder gets overwritten.
I don't want that to happen, i want to archive all the versions (because we might provide some of the old features to certain set of customers). i am just trying to understand is there way to do this in jenkins pipeline. I don't prefer plugins, it would be nice to do it declarative way using jenkins file.
First of all, it's not the best solution to store your artifacts just in target folder without any copying to other place. Usually all needed build artifacts are stored in Nexus or Artifactory repositories (of course, you can copy them to some local directory also). You can do that in pipeline Jenkinsfile as well, but you still require to install needed plugin. For example, for publishing artifacts to Nexus repo, you can use Nexus Platform Plugin, see this answer for details.
About overwriting your target folder, I'm not sure if it's cleaned by Jenkins by default. To clean workspace, you need to specify Discard old builds option in job configuration first.
Seems to be that you just execute mvn clean ... command, that's why target folder is cleaned, so I would recommend to check that first.
Is there a way to execute a maven build from command line, but disable a configured plugin without changing the pom file?
The reason for that is, that we have a number of given maven projects, which we develop together with a customer. In these projects a rpm plugin is configured, which does not run in our Windows environment. So I'd need a way to control the build in a way that it just ignores this build step without having to change the pom file (like using profiles, which I would use, if I were able to change it). Unfortunately the plugin does not have a skip property.
The only other idea I had was faking the rpm command which is called in the plugin, but this didn't work.
I am grappling to understand how Tfs’s VNext build handles NuGet.exe versions under the hood.
I am running a Tfs 2018 (16.122.27102.1) on-prem server.
My agent is running (as a windows service) on my machine on the location “C:\dev\tfs_bld_agents\scully\”
If I understand it correctly the “Nuget tool installer” (1) will ensure that the NuGet.exe version specified in the build task (in this case 4.3.0), will be installed where this build definition is executed by an agent.
The subsequent build task “NuGet Restore”(2) will then run the NuGet.exe installed by the previous build task(1) and will execute the NuGet restore command.
If, however, I search through the build agent's root folder on disk “C:\dev\tfs_bld_agents\scully\” I find an array of different versions of NuGet.exe
3.3.0
3.5.0
4.0.0
4.3.0
Directories, where a version of NuGet.exe resides, are:
What is the reason for this behaviour i.e. having all these different versions within the build agent folder, seeing that the NuGet.exe version specified by my build definition was only version 4.3.0?
Assuming that we for instance do not (or cannot in older Tfs versions) run the “NuGet Tool Installer” build task, how will the Tfs build agent go about figuring out where to find a NuGet.exe on the machine?
These NuGet.exe versions are included in the NuGet Tool Installer task and NuGet task by default. When you queue a build, build agent downloads the tasks build needs, then you will see these NuGet.exe versions.
So I performed some tests attempting to track what happens when you use different versions of NuGet within the “Nuget tool installer” Tfs build task. For the baseline, a Tfs2018 (16.122.27102.1) build agent (of type service) was used, just extracted and configured.
After configuring the build agent, you will have the following NuGet.exe in your agent directory:
NuGet.exe version: 3.3.0 (3.3.0.0212) - Note: this is just after the agent was configured, no builds have been run here!
I then proceeded to set up a build definition that will be executed by agent mulder. The build definition contained the “NuGet Tool Installer” build task. My first try was to specify NuGet 2.8.6 and then run the “NuGet Tool Installer” build task.
After this task was completed, we find the following NuGet.exe artifacts within our build agent folder:
NuGetInstaller
NuGetToolInstaller
As well as the NuGet version we requested, provided on location ...\_tool\NuGet\2.8.6\x64\nuget.exe
From this point onwards, the content of the ...\_tasks\ folder seems to remain constant in regards to NuGet.exe versions, regardless of which version you specify.
The only obvious change being, the addition of every new version you select within this location ...\_tool\NuGet\{version requested}\x64\nuget.exe.
So if we painstakingly select each possible version in the “NuGet Tool Installer” build task and run it, we will end up with a spread that looks like this:
Regarding the logging produced by the agent running the “NuGet Tool Installer” build task, the thing that stands out is the fact that after each switch in the NuGet version, the following message appears: Prepending PATH environment variable. I assume the purpose being to point to the selected NuGet.exe version on disk. In the case of version 2.8.6 we see the following:
Prepending PATH environment variable with directory: C:\TfsBuild\mulder\_work\_tool\NuGet\2.8.6\x64
So what happens if we revert back to a specific version? Let say from v4.5.1 to v2.8.6 - does it clean up some versions?
No. It leaves everything intact but does modify the PATH variable again to point to the correct version you reverted to.
Prepending PATH environment variable with directory: C:\TfsBuild\mulder\_work\_tool\NuGet\2.8.6\x64
An interesting phenomenon is that you cannot see these "Prepending" changes in your PATH environment variable.
If you, however, run the build in debug (by flipping the system.debug variable to true) you see some interesting details. This time around I can see that the variable(s) are indeed slipped in front of the existing PATH variables (that are visible in the environment variables GUI), as well as 2 more at the end.
Debug logging looks something like this:
Prepending PATH environment variable with directory: C:\TfsBuild\mulder\_work\_tool\NuGet\2.8.6\x64
new Path:
C:\TfsBuild\mulder\_work\_tool\NuGet\2.8.6\x64;
C:\TfsBuild\mulder\externals\git\cmd;
.
..
<The existing paths variables>
..
.
C:\TfsBuild\mulder\bin;
C:\TfsBuild\mulder\bin
It thus seems to retrieve the existing PATH environment variable, and then slot in the “new” required variables in front of them while running the build.
Clearly Tfs build is very good at ensuring that there is always a correct version of NuGet.exe at hand, but cleaning up old versions is not its strong suit :-)
After running maven commands, the jboss artifact sits cached in my local repo /.m2. However, it's the wrong copy, and we have updated our artifactory on the local server. How do I remove this cached copy? (other than manually deleting the jboss folder from the /.m2/repository/org folder). Is there a maven command to do so? Also, I was wondering how exactly the local repository is structured, is it according to groupId, artifactId, version (GAV) in any way?
Snapshot artifacts can be force-updated by using -U option with mvn when building a project with the dependency. Maven will take the newest snapshot available of the specified version. You have to deploy the fixed snapshot artifact to the repository before. The newest snapshot is determined by the timestamp attached to the file name of the jar.
However, release versions are not updated. Once a release artifact has been downloaded and verified, you must remove it manually if you replaced it on a remote repository. Generally, you should never replace release version artifacts. Rather you should always release a new version (and possibly delete the erroneous version from the repository) and change the pom.xml files of projects which use this artifact.
For the structure of the local/remote repository, see links below.
References:
Force maven update
maven artifact repository directory structure specs
Maven repository layout