Can someone tell me how exactly developers can acces to Nexus OSS ? Have i to install it in one server apart with Jenkins for exemple in a VM and after that what i have to do ?
Thanks.
Nexus Repository Manager is a separate application from Jenkins. You can run it in the same or a different VM. After installation you just have to configure the tools you use to connect to it for downloads and publishing and potentially configure repositories.
In terms of the tools e.g. we have a full chapter about configuring Apache Maven and others to Maven repositories as well as example projects. And similar for other formats.
All that and a lot more is covered in the documentation.
Related
I develop mostly desktop apps and class libraries, and I am struggling to find an way to host them using pipeline automation.
I know I can push them to a UNC, but then people need to know that path to find them. It works, but is not very user friendly.
What I would like is a way to host them on DevOps Server, like GitHub. On GitHub there is a Release section that you can go to and download the binaries of a project. I know Azure DevOps is geared toward webapps, but has anyone found a way to use build/release pipelines to automate the hosting of binary files?
I think what you are looking for is the Atifacts which is under the Test Plans in your project in Azure DevOps.
You can publish and download your binaries very easily here. Create a Feed and connect to it with any kinds of packages, including built in ones like NuGet and Maven, or you can customize it which called Universal packages in it.
You may find more useful information at Azure Artifacts documentation, learn what is Azure Artifacts and how you can publish and download you binaries via the CLI tool.
This is a not related to code fix, but a general approach for test automation.
I have a test automation written in javascript which runs perfectly on my machine as well as my local jenkins.
Now, i want to use my company's server(centOS) and jenkins so that it is accessible to everyone in my organization.
Issue: nodejs version in company's server need update to run my automation, but server team wont do it since they are not sure if any other functionality used be other teams may start to break because of the upgrade.
Have you faced this situation. Do you have different servers for core code and automation scripts. Please suggest.
This is a complex situation that really depends on many variables. I would recommend using an agent that contains the proper version of Nodejs. With this solution you can leave the current build server how it is but you can also use the exact version of node you need. This will require an extra server/VM with the Jenkins slave software but this will remove the need to change the master server.
The solution my company went with is using Jenkins 2.x with Declarative pipelines and ephemeral Docker containers for builds. This allows you to use any Docker image such as the official Node image. You can pin a version and build it with that. With this there is no need to worry about the version on the server. Jenkins Master doesn't even need to actually build.
i want to do release management with Jenkins but I'm confused. which artifactory should i use. Is there any opensource artifactory is there to do release management process through jenkins.I'm trying for the past month.
There is an open source version of "Artifactory" which you could use (https://bintray.com/jfrog/product/JFrog-Artifactory-Oss/view). As an alternative you can check out Nexus from sonatype: https://www.sonatype.com/nexus-repository-oss
If you don't want to install programs you can also go with a file based repository on a server. Whatever you like :)
I am currently setting up continuous integration using Visual Studio Team Services with onsite build agents, but I am having issues with my company's proxy.
I have tried adding the .proxy file but my company's proxy is still blocking it (it is a very old proxy).
Speaking to my infrastructure guys they can bypass the proxy but need all the urls that the build agent calls.
Unfortunately I can not find a list online of all the urls that it requires, I know it needs the following:
https://xxxxxxxxx.visualstudio.com
https://xxxxxxxxx.vssps.visualstudio.com
Does anyone know all the other urls that an onsite build agent calls?
It's hard to tell, the agent itself uses a number of URI's connect, the ones I know of are these at least:
account.visualstudio.com
account.vsrm.visualstudio.com
account.vssps.visualstudio.com
app.vssps.visualstudio.com
But then there are a number of tasks that need download access as well, e.g.
npm needs access to www.npmjs.com
Sonar Qube needs to download the sonar runner
NuGet needs access to www.nuget.org to restore packages
...
Then depending on which extensions you use, you may need additional ones
My Snyk task needs access to snyk.io for example
The easiest way to find them all is to setup a build agent outside of your company network and monitor the traffic with fiddler. To get an answer from the source I recommend to post an issue on the vsts-agent github repo.
We are using maven in the development process. Maven provides a nice feature of configuring the repositories. Using this feature I have created a remote internal repository and I can download the dependencies from that repository.
The development machines are pointing to this remote internal repository. Each development machine has its own local repository(~/.m2/repository/) and hence the dependencies of the project are downloaded from the remote internal repositor**y to the **local repository(~/.m2/repository/) on each developer machine.
Is there any way that the local repository(~/.m2/repository/) on developer machines can be set to the internal remote repository that we have created and which is used for downloading the dependencies from.
If take a look on Maven Introduction to Repositories first paragraph says:
There are strictly only two types of repositories: local and remote.
There is no way how you could change this behavior.
If you would handle that differently it would cause many problems. E.g. build would take much longer because of downloading file all files, IDE would work not work properly (project dependencies would not be stored local), ...
May I suggest another approach to share dependencies and artifacts. In our projects we use nexus as a proxy and repository for our artifacts. It works well with no issues. A basic configuration I already posted here.
After nexus is running you could also setup continous integration using jenkins and enjoy a fully automated environment.
Is your requirement to avoid each developer from having to download all dependencies to his local repository?
Assuming your remote internal repository has the same format as a maven local repository, you can achieve this by adding the following line in the settings.xml of all your developers.
<localRepository>shared-drive-location-of-remote-repository</localRepository>