[JIRA] (JENKINS-10449) Excluded regions do not exclude commits from changelog
kutzi commented on JENKINS-10449 Excluded regions do not exclude commits from changelog I'm not sure that this is a feature every user wants to have. I for my case would like to see the whole changelog even if not every commit would trigger a new build. So I think this should be configurable. BTW: if you're in a situation like these and need to exclude certain regions, it might be a signal that your subversion repository should be modularized. 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-16139) Copy Artifacts of specific build number fails if build is triggered by upstream project.
Stefan Heule created JENKINS-16139 Copy Artifacts of specific build number fails if build is triggered by upstream project. Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: copyartifact Created: 15/Dec/12 9:16 AM Description: We have the following setup: Three projects A, B and C, where a successful build of A triggers a build of B, which in turn triggers C (i.e. C depends on B, and B depends on A). Both A and B archive some artifacts, and the first step of B's build is to fetch the artifacts of A, and the first step of C's build is to fetch artifacts for both A and B. Now we want a specific build artifact of A (not the latest one) in project C and use the "specific build" option and giving a build number for which artifacts exist. Now, the build of C fails with "Unable to find a build for artifact copy from: A" if the build is triggered by the upstream project B. Building C manually seems to work initially, but once the build failed for the reason mentioned, only a Jenkins restart fixes the issue. As a workaround, it seems that using "latest saved build" works. Environment: Jenkins 1.493 running on Windows Server 2008 with Copy Artifacts 1.25 Project: Jenkins Priority: Major Reporter: Stefan Heule 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-14116) Updating to specific revision doesn't work
kutzi commented on JENKINS-14116 Updating to specific revision doesn't work For reference: this is the pull request https://github.com/jenkinsci/subversion-plugin/pull/17 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-16140) Clock on this slave is out of sync with the master
D D created JENKINS-16140 Clock on this slave is out of sync with the master Issue Type: Bug Assignee: Gregory Boissinot Components: xunit Created: 15/Dec/12 9:50 AM Description: We are running test on virtual machines. Clock is not synched. I am cleaning the workspace before starting the test, so there is no danger of missing the right report. All our tests are failing because of this. If this is not fixed we will be forced to remove this plugin from use. Project: Jenkins Priority: Blocker Reporter: D D 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-10449) Excluded regions do not exclude commits from changelog
Brent Atkinson commented on JENKINS-10449 Excluded regions do not exclude commits from changelog I agree, that was my first reaction as well. If you're doing this systematically it will be an uphill battle and definitely suggests you're fighting your tooling. However, when considering the reasons to exclude parts of the tree from triggering a build, I couldn't generate reasonable arguments for including those changes in the changelog. If the commits will be noise for the builds, it seems to follow that they'll be noise in changelog as well. That's when I started looking at this differently and started working on a solution. Would you mind sharing your rationale? Why would you want to see the logs from excluded regions and not verify the project stability by building? Understanding the common reasons for using exclusions/inclusions might help steer others clear of expecting this. 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-10449) Excluded regions do not exclude commits from changelog
kutzi commented on JENKINS-10449 Excluded regions do not exclude commits from changelog One part of the reasoning is that these changes are actually checked out into the workspace, therefore I'd like to see them. Other part is that even if you think that the changes may not be relevant for the build, you may be wrong and suddenly the build starts failing without any changelog entry. Also I think that most of the time the additional changelog entries will do no harm, so I just would like to see them for completeness (see point 1 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-15806) Exit code of `hg pull` not checked
Rene Kroon
updated JENKINS-15806
Exit code of `hg pull` not checked
Change By:
Rene Kroon
(15/Dec/12 12:49 PM)
Description:
See pull request @ https://github.com/jenkinsci/mercurial-plugin/pull/31
Currently it appears that the Mercurial plugin doesn't check the exit code of the {{hg pull}} used to update the repository (see {{hudson.plugins.mercurial.MercurialSCM#update()}} - https://github.com/jenkinsci/mercurial-plugin/blob/master/src/main/java/hudson/plugins/mercurial/MercurialSCM.java#L496)So, if the upstream repo has gone away for some reason (say, hypothetically, I've rm-ed it), the {{hg pull}} will fail and exit with a status code of 255, but the build will continue regardless
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-15806) Exit code of `hg pull` not checked
Rene Kroon started work on JENKINS-15806 Exit code of `hg pull` not checked Change By: Rene Kroon (15/Dec/12 12:48 PM) Status: Open In Progress 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-15806) Exit code of `hg pull` not checked
Rene Kroon assigned JENKINS-15806 to Rene Kroon Exit code of `hg pull` not checked Change By: Rene Kroon (15/Dec/12 12:51 PM) Assignee: Jesse Glick Rene Kroon 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-16141) 'site-deplpoy' adds empty entries to the list of deployed artifacts
domi
updated JENKINS-16141
'site-deplpoy' adds empty entries to the list of deployed artifacts
Change By:
domi
(15/Dec/12 2:18 PM)
Description:
if a build also deploys the generated site to a remote host, the 'maven-deployment-linker' plugin adds each page as a deployed artifact to the list.But these artifacts are added in a wrong way, the list is created with html like this:
{{
}}
as you can see in the html and on the picture, there is no text added to the list items, only an anker tag.I think the plugin should ignore the files generated by the site plugin at all.
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-16141) 'site-deplpoy' adds empty entries to the list of deployed artifacts
domi
created JENKINS-16141
'site-deplpoy' adds empty entries to the list of deployed artifacts
Issue Type:
Bug
Assignee:
Larry Shatzer, Jr.
Attachments:
linked_artifacts.jpg
Components:
maven-deployment-linker
Created:
15/Dec/12 2:17 PM
Description:
if a build also deploys the generated site to a remote host, the 'maven-deployment-linker' plugin adds each page as a deployed artifact to the list.
But these artifacts are added in a wrong way, the list is created with html like this:
{{
http://XXX:8081/nexus/content/sites/somepath/ABCED_Plugin/">
http://XXX:8081/nexus/content/sites/site/somepath/maven-plugins/ABCD_Plugin/">
}}
as you can see in the html and on the picture, there is no text added to the list items, only an anker tag.
I think the plugin should ignore the files generated by the site plugin at all.
Project:
Jenkins
Priority:
Major
Reporter:
domi
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-10449) Excluded regions do not exclude commits from changelog
Brent Atkinson commented on JENKINS-10449 Excluded regions do not exclude commits from changelog Thanks for explaining, I agree with your reasoning and it matches my initial thinking. My personal preference would be to never exclude and use proper sub-trees. However, assuming that there are valid reasons for exclusion, which is suggested by the fact it exists: If it affects the build, it's a misconfiguration to exclude something that matters. You want to run verification on relevant changes. If there are a lot of them, like developer docs needing locality to code, you don't want to be spammed with those changes When excluding noisy edits that aren't functionality related. The full changelog may actually do more to hide changes in noise. Ultimately, you want the misconfiguration fixed because you were wrong to exclude in the first place. I can see valid cases where the changes in the excluded area are particularly long and it's unlikely they'll be affecting anything, docs for example. I also can see wanting to have those edits omitted from the stream rather than spamming on the next build. It's the same reasoning, but a simulation of http://svnbook.red-bean.com/nightly/en/svn.advanced.sparsedirs.html 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-10449) Excluded regions do not exclude commits from changelog
kutzi commented on JENKINS-10449 Excluded regions do not exclude commits from changelog You don't have to convince me that there are lots of good use cases to exclude the changes from the changelog. I'd even say that these use cases are more relevant than my use cases. Unfortunately, to exclude the changes from the changelog is a backward incompatible change and should therefore (IMHO) be configurable. Who knows, maybe someone else has a perfectly reasonable usecase to not exclude the changes and he would be negatively affected by this change. 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-10449) Excluded regions do not exclude commits from changelog
Brent Atkinson commented on JENKINS-10449 Excluded regions do not exclude commits from changelog I agree, configuration would make it far less controversial. I apologize if I am belaboring it, but it helps to think it through and document the reasoning. I am definitely not trying to convert you. Like I said, my own preference would be to avoid the complication. 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-15993) Add an option to send only one message for multi-configuration builds
camico resolved JENKINS-15993 as Cannot Reproduce Add an option to send only one message for multi-configuration builds Sorry, didn't notice it already exists... Change By: camico (15/Dec/12 7:13 PM) Status: Open Resolved Fix Version/s: current Resolution: Cannot Reproduce 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
