I want to upload an artifact from Jenkins running on Cloudbees to Nexus central, since my one is an OSS project stored in Maven Central. To do so, I need to install gpg keys locally. How can I do this on Cloudbees. I've done it on my local Linux box but I'd need access to some sort of Linux environment on Cloudbees.
Regards,
Marco
You can upload your gpg key to your private repository on cloudbees forge, and set maven job to use -Dgpg.homedir=/private/
Related
I have a build machine for Android app. This machine has no access to the Internet.
There is a local nexus repository. Application gradle set up to load dependencies from this nexus repository and it works fine.
But I also need gradlew to load from that nexus repository too.
I've tried to set distributionUrl to local nexus url and it works - distribution is installed and daemon is started.
But next it fails to load https://dl.google.com/android/repository/addons_list-5.xml with timeout
Is there a way to redirect all gradle requests to nexus repositories?
To redirect all Gradle requests to your Nexus repository, you can add the following to your gradle.properties file:
systemProp.http.proxyHost=<hostname>
systemProp.http.proxyPort=<port>
systemProp.http.nonProxyHosts=localhost|127.0.0.1
Replace and with the hostname and port of your Nexus repository. This will tell Gradle to use your local Nexus repository for all dependencies, including the addons_list-5.xml file that you are currently having trouble loading.
It's also a good idea to make sure that your Nexus repository is properly configured and has all the necessary dependencies. You can check the logs of your Nexus repository to see if there are any errors or issues that might be preventing Gradle from accessing the dependencies it needs.
I would like to do a backup artifactory. My artifactory is started by docker in VM. Arti version 6.12 in default configurations.
<config version="1">
<chain template="file-system"/>
</config>
The metadata is stored in a Derby database (by default). All files are mounted in the volume /art/data (docker ... -v /art/data/arti.docker.home:/var/opt/jfrog/artifactory)
Artifact and database are about 1TB
I don't want to use build-in backup mechanism from the UI. I'm going to make backup /art/data. Is it a proper aproche?
Anything that would allow you a swift restore is a valid approach.
I advise you to test a restore scenario from the backup you plan to take. If you are able to restore successfully - you can implement this solution.
My employer has been misusing Bintray as our binary repository for some time. We are finally moving to Artifactory instead and closing down Bintray. But this seems to be an almost impossible task. There is no way of exporting Bintray repos to a zip. Downloading the repos means manually downloading each file from the UI or through their API. I have tried two approaches for automation:
1) wget for crawling our bintray like this:
wget -e robots=off -o ~/wget.log -w 1 -m -np --user --password "https://.bintray.com"
which yielded all of the files in the repos. But this only solves half the problem. I couldn't find out how to import the files to a repository in artifactory (all the repos are over 100mbs each and therefore can't be uploaded, for some reason).
2) I set the Bintray repos up as remote repositories and enabled Active Replication. That seems to have worked for now. But I don't know if they will be removed when the Bintray account is moved or even if they are stored in Artifactory. Therefore I would like to convert the remote repo to a local repo, to make sure that it is permanently stored in artifactory is there a way of doing this? If so, how?
I'll try to address both of your questions below.
What do you mean you can't upload more than 100mb? Which version of Artifactory are you using? On-prem or SaaS-based installation? How are you trying to upload your files to Artifactory? Have you tried to import the content by using the import feature of Artifactory? (Admin --> Import&Export --> repository Import)
It sounds like you are using the UI for the upload, and if so you can configure the max upload size in Admin --> General Configuration page.
If you mean that you have all of the content from Bintray cached in your remote repository cache in Artifactory just use the "Copy" or "Move" option and move the content to a local repository. This will ensure that all of the content is stored locally.
the situation is next:
we have few repositories in local Sonatype Nexus OSS for two env, it is a "site" and "hosted repositories".
Jenkins uploads there builds, currently it is a zip files with *.bin inside, In particular Nexus repo I see list of files, like:
*_$BUILD_1.zip
*_$BUILD_2.zip
...
*_$BUILD_n.zip
I want to have Rundeck job to chose appropriate version from appropriate repo to deploy, I set up nexus-rundeck-plugin in nexus, and nexus-step-plugins in Rundeck, I thought, evrth will be ok, but rundeck-nexus steps require things like "Group", "Artifact", "Version", "Packaging", "Classifer", and I do not have these parameters for my *.zip files in local Nexus repo, do you have any suggestion how can I integrate this things?
when i install Nexus war into my tomcat server Nexus creating its folder etc at Win home directory. I want to redirect this to my different directory.
Meaning.. I want nexus to store its repository in user defined folder
How to do this ?
You should set the environment variable PLEXUS_NEXUS_WORK to your user defined folder in your the /bin/setenv.cmd file and restart Tomcat before deploying the Nexus web application.
I don't have a Windows example handy but here is the /usr/share/tomcat7/bin/setenv.sh on my Linux deployment:
#! /bin/sh
export PLEXUS_NEXUS_WORK=/var/nexus
I assume that the Windows equivalent might be:
SET PLEXUS_NEXUS_WORK=C:\NEXUS
Setting the PLEXUS_NEXUS_WORK environment variable didn't work for me using Tomcat 7 and Nexus 2.8. Perhaps this no longer works with newer versions of Nexus.
What did work was to change the nexus-work setting in nexus.properties file, which is in the WEB-INF/classes folder of the Nexus web app
Here is what my setting now looks like:
nexus-work=D:/sonatype-work/nexus
I would suggest to use the Nexus bundle installer with the embedded jetty server instead of running the Jetty war in Tomcat. While you can do that, you will not be able to upgrade to Nexus Professional easily since it is only supported with the embedded Jetty.
If you use the bundle installer the storage will be in a sibling folder to the nexus folder called sonatype-work/nexus.
Check out the free book Repository Management with Nexus for more info.
Since Nexus 2.8, you could set the nexus-work as an environment parameter for the tomcat JVM, like this :
JAVA_OPTS="-d64 -server -Xms128M -Xmx1024M -XX:MaxPermSize=512M -Dcom.sun.security.enableCRLDP=true -Djava.net.preferIPv4Stack=true -Djava.io.tmpdir=/tmp -Dnexus-work=/var/lib/nexus/work "
It works for me as I have the Nexus OSS as a war file into a RHEL6 tomcat6 installation.