[JIRA] [artifactory-plugin] (JENKINS-26403) SNI Support when using Artifactory behind HTTPS
yossis commented on JENKINS-26403 SNI Support when using Artifactory behind HTTPS We upgraded the http client to support SNI. Please track the issue on the official plugin Jira - https://www.jfrog.com/jira/browse/HAP-556 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [artifactory] (JENKINS-23650) artifactoryPublish fails with Gradle 2.0
yossis commented on JENKINS-23650 artifactoryPublish fails with Gradle 2.0 please follow this issue: https://www.jfrog.com/jira/browse/GAP-153 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [artifactory] (JENKINS-19005) Cannot deploy on Artifactory
yossis resolved JENKINS-19005 as Duplicate Cannot deploy on Artifactory Duplicates https://www.jfrog.com/jira/browse/HAP-420. Will be fixed in version 2.1.7 Change By: yossis (31/Jul/13 12:28 PM) Status: Open Resolved Resolution: Duplicate This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [artifactory] (JENKINS-19005) Cannot deploy on Artifactory
yossis commented on JENKINS-19005 Cannot deploy on Artifactory A fixed version will be released soon. Please watch https://www.jfrog.com/jira/browse/HAP-420 for more details. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-16465) Maven3Builder don't handle ToolInstallers
yossis commented on JENKINS-16465 Maven3Builder don't handle ToolInstallers The freestyle builder exists for some time and it is still used. I opened an issue on our issue tracker https://issues.jfrog.org/jira/browse/HAP-374 and we will check how we can adjust it to work with the latest changes in Jenkins. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12025) Git support in Artifactory release broken as GitAPI.java changed
[ https://issues.jenkins-ci.org/browse/JENKINS-12025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163724#comment-163724 ] yossis commented on JENKINS-12025: -- Thanks Nicolas! > Git support in Artifactory release broken as GitAPI.java changed > > > Key: JENKINS-12025 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12025 > Project: Jenkins > Issue Type: Bug > Components: artifactory >Affects Versions: current > Environment: Latest Jenkins 1.442 under Ubuntu. >Reporter: ravn >Assignee: yossis > > Artifactory Release (2.0.4) works with Git plugin 1.1.12, but fails with Git > plugin 1.1.14. > [RELEASE] Release build triggered > FATAL: > hudson.plugins.git.GitAPI.(Ljava/lang/String;Lhudson/FilePath;Lhudson/model/TaskListener;Lhudson/EnvVars;)V > java.lang.NoSuchMethodError: > hudson.plugins.git.GitAPI.(Ljava/lang/String;Lhudson/FilePath;Lhudson/model/TaskListener;Lhudson/EnvVars;)V > at > org.jfrog.hudson.release.scm.git.GitManager.createGitAPI(GitManager.java:158) > at > org.jfrog.hudson.release.scm.git.GitManager.access$100(GitManager.java:42) > at > org.jfrog.hudson.release.scm.git.GitManager$CurrentCommitCallable.invoke(GitManager.java:188) > at > org.jfrog.hudson.release.scm.git.GitManager$CurrentCommitCallable.invoke(GitManager.java:168) > at hudson.FilePath.act(FilePath.java:783) > at hudson.FilePath.act(FilePath.java:765) > at > org.jfrog.hudson.release.scm.git.GitManager.getCurrentCommitHash(GitManager.java:52) > at > org.jfrog.hudson.release.scm.git.GitCoordinator.prepare(GitCoordinator.java:74) > at > org.jfrog.hudson.release.maven.MavenReleaseWrapper.setUp(MavenReleaseWrapper.java:132) > at > hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:605) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:462) > at hudson.model.Run.run(Run.java:1404) > at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:238) > According to > https://github.com/jenkinsci/git-plugin/compare/git-1.1.12...git-1.1.14#diff-2 > GitAPI.java method called was changed in 1.1.13, adding a parameter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13917) Artifactory plugin libraries affecting the path used during an Ant build
[ https://issues.jenkins-ci.org/browse/JENKINS-13917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163312#comment-163312 ] yossis commented on JENKINS-13917: -- This library is not distributed with Artifactory plugin. Are you using an old version? > Artifactory plugin libraries affecting the path used during an Ant build > > > Key: JENKINS-13917 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13917 > Project: Jenkins > Issue Type: Bug > Components: artifactory >Affects Versions: current > Environment: Linux (CentOS 6) >Reporter: Camden Holt >Assignee: yossis > > We have a job using an Ant script to perform the build. One of the targets > in this script generates instrumented classes to enable us to generate a > Cobertura coverage report. > As part of our set of standard libraries, we include various jars from the > slf4j suite. When we enable the Artifactory plugin for this job, the > Cobertura Ant target fails, because of an incompatible set of jars being > used. The snippet of output below is generated with verbose logging from the > VM: > 12:19:40 cobertura-instrumented-src-classes: > 12:19:40 [Loaded net.sourceforge.cobertura.ant.CommonMatchingTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.InstrumentTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.MergeTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.CheckTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.ReportTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.Ignore from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.IgnoreBranches from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.IncludeClasses from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.ExcludeClasses from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded org.apache.tools.ant.taskdefs.ImportTask from > file:/opt/apache-ant-1.8.1/lib/ant.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.util.CommandLineBuilder from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded org.apache.log4j.Category from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/log4j-over-slf4j-1.6.4.jar] > 12:19:40 [Loaded org.apache.log4j.Logger from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/log4j-over-slf4j-1.6.4.jar] > * 12:19:40 [Loaded org.slf4j.MarkerFactory from > file:/opt/jenkins/plugins/artifactory/WEB-INF/lib/slf4j-api-1.5.8.jar] > 12:19:40 [Loaded org.apache.tools.ant.util.DateUtils from > file:/opt/apache-ant-1.8.1/lib/ant.jar] > The line prefixed with * shows the problem; the slf4j-api-1.5.8.jar is being > loaded from the artifactory plugin directory. This is an older version than > that supplied with our project which is 1.6.4 - and this is causing a problem > when the compilation step occurs. > When we run this from the command line using ant directly we can see that > the correct jar from within our project is loaded. > I'm afraid I don't understand fully how the addition of plugins affects the > build environment technically, but I assume that the Artifactory plugin has > been able to modify the environment/build path somehow to ensure that it's > available at the appropriate time. Unfortunately this seems to cause problems > if newer libraries are needed elsewhere. > We can work around this by using the Ant/Ivy/Artifactory integration from the > build script directly, but it would be good to be able to do this from > Jenkins and simplify our scripts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13384) Cannot archive artifact - NTFS symlink
[ https://issues.jenkins-ci.org/browse/JENKINS-13384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161892#comment-161892 ] yossis commented on JENKINS-13384: -- How is it related to Artifactory? The archiving is not done by the Artifactory plugin. BTW, with Artifactory plugin, artifacts archiving is not required for deployment to the repository. > Cannot archive artifact - NTFS symlink > -- > > Key: JENKINS-13384 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13384 > Project: Jenkins > Issue Type: Bug > Components: artifactory > Environment: Windows Slave: > - Windows Server 2008 R2 SP1 64 bit > - C: is NTFS filesystem > - Sun Java 1.6.0_20 > Master: > - Jenkins 1.460 > - Red Hat Enterprise Linux 5.5 64 bit > - Sun Java 1.6.0_20 >Reporter: Ben Golding >Assignee: yossis >Priority: Minor > Attachments: artifact_exception.log > > > Steps to reproduce: > # Open slave command prompt > > mkdir C:\test > > cd /d C:\test > > notepad file.txt > # Write something, save > > mklink linked.txt file.txt > # Note linked.txt is an NTFS symlink > # Open Jenkins web interface > # New Job > # Name 'test' > # 'Build a free-style software project' > # OK button > # Check 'Restrict where this project can be run', enter Windows slave name > # Check 'Use custom workspace', enter Directory: C:\test > # Check 'Archive the artifacts', enter Files to archive: file.txt,linked.txt > # Save button > # Build Now link > # When complete, click the link for Build #1 > # Note 'linked.txt' appears with a size 0, while file.txt is size 15 bytes > # Click 'Console Output' link, errors seen: (artifact_exception.log is > attached) > - > Expected behaviour is: make a copy of the symlinked file as a regular file > - > Below are some types of "link" you may wish to consider for MS Windows. > Jenkins does not necessarily need to support all. > Should be transparent to applications: > * NTFS file and directory symlinks (Win Vista and later) > * junction points (also supported on Win XP, ...) > Non-transparent: > * Windows Explorer shortcuts (.lnk) ? > * Cygwin symlinks ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9190) deduplicating build artifacts
[ https://issues.jenkins-ci.org/browse/JENKINS-9190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] yossis resolved JENKINS-9190. - Resolution: Duplicate > deduplicating build artifacts > - > > Key: JENKINS-9190 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9190 > Project: Jenkins > Issue Type: Improvement > Components: artifactory >Affects Versions: current >Reporter: Brian Murrell >Assignee: yossis > > At least in our case, a project can produce quite a number of artifacts, some > quite large and some which only change occasionally from one build to another > (i.e. some artifacts change every time, some less frequently). It seems that > both space and bandwidth could be saved by de-duplicating these seldom > changed artifacts from one build to another. > I imagine an algorithm where the server keeps a database of sums and sizes of > stored artifacts and when a slave is going to send the artifacts of a build > it first offers the sums and sizes of the artifacts. If the server finds > potential matches, further verification of duplication could be performed > (i.e. comparing random samples of the suspected duplicates) and once a > duplicate has been confirmed, the server can either copy or link the artifact > locally and tell the slave not to bother sending it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9190) deduplicating build artifacts
[ https://issues.jenkins-ci.org/browse/JENKINS-9190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161613#comment-161613 ] yossis commented on JENKINS-9190: - This is possible in Artifactory using what we call ["checksum deploy"|http://wiki.jfrog.org/confluence/display/RTF/Artifactory%27s+REST+API#ArtifactorysRESTAPI-DeployArtifactbyChecksum]. Support in Jenkins plugin is coming in the next version. We'll probably use it only for artifacts bigger that 10KB. You can follow the following issue: https://issues.jfrog.org/jira/browse/BI-126. > deduplicating build artifacts > - > > Key: JENKINS-9190 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9190 > Project: Jenkins > Issue Type: Improvement > Components: artifactory >Affects Versions: current >Reporter: Brian Murrell >Assignee: yossis > > At least in our case, a project can produce quite a number of artifacts, some > quite large and some which only change occasionally from one build to another > (i.e. some artifacts change every time, some less frequently). It seems that > both space and bandwidth could be saved by de-duplicating these seldom > changed artifacts from one build to another. > I imagine an algorithm where the server keeps a database of sums and sizes of > stored artifacts and when a slave is going to send the artifacts of a build > it first offers the sums and sizes of the artifacts. If the server finds > potential matches, further verification of duplication could be performed > (i.e. comparing random samples of the suspected duplicates) and once a > duplicate has been confirmed, the server can either copy or link the artifact > locally and tell the slave not to bother sending it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
