[JIRA] (JENKINS-26033) Document and test return value for parallel
Title: Message Title Craig Silverstein closed an issue as Fixed I think this is done now. Jenkins / JENKINS-26033 Document and test return value for parallel Change By: Craig Silverstein Status: Open Closed Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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] (JENKINS-26034) Option to interrupt remaining branches when one branch fails
Title: Message Title Craig Silverstein closed an issue as Fixed We have `failFast` now! Jenkins / JENKINS-26034 Option to interrupt remaining branches when one branch fails Change By: Craig Silverstein Status: Resolved Closed Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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] (JENKINS-29522) Rename master/slave to manager/worker
Title: Message Title Craig Silverstein closed an issue as Duplicate Seems like it's been resolved! Jenkins / JENKINS-29522 Rename master/slave to manager/worker Change By: Craig Silverstein Status: Resolved Closed Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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] (JENKINS-41584) Plugin functionality missing in pipeline API
Title: Message Title Craig Silverstein created an issue Jenkins / JENKINS-41584 Plugin functionality missing in pipeline API Issue Type: New Feature Assignee: Kohsuke Kawaguchi Components: build-timeout-plugin Created: 2017/Jan/31 4:55 AM Environment: build-timeout-plugin 1.18 Labels: pipeline timeout Priority: Minor Reporter: Craig Silverstein At https://wiki.jenkins-ci.org/display/JENKINS/Build-timeout+Plugin, it says "This plugin isn't applicable to pipelines. Use timeout step in workflow-basic-steps instead." This is true for the "absolute" strategy, and without much difficulty for the "deadline" strategy, but there is no clear way to use the timeout step for "elastic", "likely stuck," or (our go-to) "no activity." What is the suggest way to achieve the no-activity functionality in a pipelines world? Would it be possible to modify this plugin to work with pipelines, so we could get that functionality by using this plugin?
[JIRA] [core] (JENKINS-27268) "dumb" slave?
Title: Message Title Craig Silverstein commented on JENKINS-27268 Re: "dumb" slave? master/minion is kinda cute. "Minion" is an anthropocentric word in that it's used to describe a type or role of a person, but it's not really a serious one (that is, one that people use non-ironically). So that pairing has a kind of fairy-tale association, rather than a real-world association, which makes it more palatable. Of course, these days master/minion would make one think of http://www.minionsmovie.com/minions.html Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [core] (JENKINS-27268) "dumb" slave?
Title: Message Title Craig Silverstein commented on JENKINS-27268 Re: "dumb" slave? > We will do the rename Great news! Thanks, craig Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [core] (JENKINS-27268) "dumb" slave?
Title: Message Title
Craig Silverstein commented on JENKINS-27268
Re: "dumb" slave?
I also wanted to give kudos for having the transcript of the meeting publicly available. I've never seen such a successful job of a meeting being run over IRC!
It was unclear to me what the outcome of the meeting was, but it seemed to be that no action would be taken with respect to renaming 'master' and 'slave'. I have a few thoughts that I'm hoping can sway the outcome otherwise:
While many people might recognize 'master'/'slave' as longstanding (if unfortunate) technical terminology and accept it without qualms, there are definitely people who will be affected by the ugly history behind those words and will be put off the Jenkins project as a result. I think it's worthwhile to make an effort to accomodate those people, and thus not only grow the Jenkins userbase but also send a message to the public that Jenkins is a project that aims to accomodate a wide range of users.
Changing the UI, while leaving the internal names alone, would give 90+% of the benefit for <10% of the cost. I think this would make a great first step.
I think you could rename the internal names while keeping backwards compatibility for all plugins via an empy subclass, like so (psuedocode):
class WorkerFoo() {
for SlaveFoo>
};
class SlaveFoo(subclass WorkerFoo) {
// Deprecated; use WorkerFoo for all new code
};
You could even add deprecation-warning log messages in the SlaveFoo constructor, to encourage plugin authors to rename the class for their next upgrade. (Or add deprecation warnings sometime in the future.)
As a bit of background for those who may not be tuned into some of the language sensitivies here: 'slave' is an objectionable term no matter what, and renaming 'slave' to something else would be a necessary part of this process. Renaming 'master' is a more subtle issue. Basically, 'master' by itself does not necessarily have bad associations, but the more you see 'master' paired with another anthropocentric word, the worse its associations get. So 'master/slave' is really bad, 'master/worker' is borderline, 'master/agent' would be ok to most people I'm guessing, and 'master/subprocess' or some such would be unobjectionable. (Just in case renaming 'slave' turns out to be a lot easier than renaming both 'slave' and 'master'.)
[JIRA] [core] (JENKINS-29522) Rename master/slave to manager/worker
Title: Message Title Craig Silverstein created an issue Jenkins / JENKINS-29522 Rename master/slave to manager/worker Issue Type: Improvement Assignee: Unassigned Components: core Created: 20/Jul/15 9:19 PM Environment: All Priority: Minor Reporter: Craig Silverstein How receptive would the jenkins community be to replacing the master/slave terminology? Django and drupal have already made such a switch – https://github.com/django/django/pull/2692, https://www.drupal.org/node/2275877 – and I think their reasoning applies to Jenkins as well. (One could bikeshed indefinitely on replacement terms, and I'm not wedded to manager/worker in any way.) Changing the code is probably the easier part (though not trivial); there's also lots of documentation that would need to change, not all of it written/maintained by the jenkins project. I think the proejct is worth it even if there is a long tail of references to master/slave references that stick around in docs.
[JIRA] [scm-sync-configuration-plugin] (JENKINS-26204) Plugin gets confused when I add and delete in quick succession
Craig Silverstein created JENKINS-26204 Plugin gets confused when I add and delete in quick succession Issue Type: Bug Assignee: Frédéric Camblor Components: scm-sync-configuration-plugin Created: 22/Dec/14 11:30 PM Description: I created a new jenkins job and then deleted it a few seconds later, after deciding I wanted to use a different name. The scm-sync-configuration plugin got into a bad state, presumably because it was trying to combine the add and delete into the same commit. Here are the logs: — Dec 22, 2014 3:13:56 PM FINEST hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness Processing commit : Commit hudson.plugins.scm_sync_configuration.model.Commit@6bdc2d06 : Author : Craig Silverstein Comment : Job [test-new-git] hierarchy deleted by csilv...@khanacademy.org Changeset : A jobs/test-new-git/config.xml D jobs/test-new-git Dec 22, 2014 3:13:56 PM FINE hudson.plugins.scm_sync_configuration.SCMManipulator Deleting SCM hierarchy [/var/lib/jenkins/scm-sync-configuration/checkoutConfiguration/jobs/test-new-git] from SCM ... Dec 22, 2014 3:13:56 PM SEVERE hudson.plugins.scm_sync_configuration.SCMManipulator deleteHierarchy [deleteHierarchy] Problem during remove : The git command failed. — I'm not even sure how to fix this manually. But would be great if the plugin could not get into this state to begin with. Project: Jenkins Priority: Minor Reporter: Craig Silverstein 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] [git-client-plugin] (JENKINS-25387) JGit in git client should support reference repositories
Craig Silverstein commented on JENKINS-25387 JGit in git client should support reference repositories Mark, thanks for your response. You're right that I am assuming that the repo that we're referencing has the same directory structure as our repo – that is, that the submodules are in the same location in both cases. I think for jenkins, the common case is that you have to clone a repo in a number of different workspaces, and would like them all to --reference a common repo to speed up their fetches. In that case, all repos have the same structure, so using $refdir/$repo will work. (Note that $repo in my pseudocode isn't the name of a repo or anything like that, it's the directory that the submodule lives in inside the 'main' repo. I probably misnamed it. If all occurrences of $repo above were renamed to $submodule_dir, would that help? ) 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] [git-client-plugin] (JENKINS-25387) JGit in git client should support reference repositories
Craig Silverstein
commented on JENKINS-25387
JGit in git client should support reference repositories
Stephan, I have a kinda-crazy feature request: would it be possible to augment this functionality to also use reference repos for submodules? In our use case, we have a submodule that is as large as our 'main' module.
git submodule update supports the `--reference` flag, so I think this would be replacing the current `git submodule update --init --recursive` with something like (bash-style psuedocode):
git submodule init
refdir=`cat .git/objects/info/alternates`
for repo in `git submodule status | awk '{print $2}'`; do
if [ -d "$refdir/../modules/$repo/objects ]; then
git submodule update --reference $refdir/$repo --recursive -- $repo
else
git submodule update --recursive -- $repo
fi
done
(Though I admit I'm confused by how git references play around with submodules, so maybe the above won't work. It seemed to in my testing, at least.)
Thanks!
craig
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] [workflow-plugin] (JENKINS-26034) Add support for sibling-cancel in parallel().
Craig Silverstein commented on JENKINS-26034 Add support for sibling-cancel in parallel(). Right, looks like we came up with the exact same approach! Works for me. 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] [workflow-plugin] (JENKINS-26034) Add support for sibling-cancel in parallel().
Craig Silverstein
commented on JENKINS-26034
Add support for sibling-cancel in parallel().
Sorry, I knew I'd get the terminology wrong!
It sounds from JENKINS-26033 that you're leaning towards not having a (meaningful) return value from 'branch'. So if I want to record the fact a particular branch failed, I'd have to swallow the exception and rethrow (to cause the sibling-cancel) – at least, I assume the rethrow would cause the sibling-cancel.
Just thinking out loud about the following use-case: I want to run two tasks in parallel. If either one fails, I want to cancel the other, and then continue executing my job. How would I do that in a world where 'cancel_siblings' was an option to 'parallel'. I guess it would be something like this:
def one_failed, two_failed;
try {
parallel one: {
try {
...
} catch (x) {
_one_failed_ = true
// Need to rethrow to cause parallel to cancel job two
rethrow // I assume this is a thing?
}
}, two: {
try {
...
} catch (x) {
two_failed = true
rethrow
}
}
} catch (x) {
}
... continue on, looking at one_failed and two_failed if needed ...
It's a little messy but I believe it works. I doubt this is a super-common case, so as long as it's possible I think this design works for our needs, at least.
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] [workflow-plugin] (JENKINS-26033) Document and test return value for parallel
Craig Silverstein commented on JENKINS-26033 Document and test return value for parallel This makes sense to me. (I wonder how this design decision would affect JENKINS-26034, but I'll put my comments about that there.) 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] [workflow-plugin] (JENKINS-26033) Document and test return value for parallel
Craig Silverstein created JENKINS-26033 Document and test return value for parallel Issue Type: Bug Assignee: Jesse Glick Components: workflow-plugin Created: 12/Dec/14 12:48 AM Description: As recorded in https://groups.google.com/d/msg/jenkinsci-dev/kgEc7vZQgi0/IC1rH_6KwNYJ: — > does 'parallel' have a return value? It does not seem to be documented (and perhaps not tested) but it does seem to return a map of the return values of its branches. File an issue to make sure this is documented and tested (and works). — I marked this as a 'bug' though arguably it's a feature request. Environment: workflow plugin 1.1 Project: Jenkins Priority: Minor Reporter: Craig Silverstein 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] [workflow-plugin] (JENKINS-26034) Add support for sibling-cancel in parallel().
Craig Silverstein created JENKINS-26034 Add support for sibling-cancel in parallel(). Issue Type: Improvement Assignee: Jesse Glick Components: workflow-plugin Created: 12/Dec/14 12:52 AM Description: As recorded in https://groups.google.com/d/msg/jenkinsci-dev/kgEc7vZQgi0/IC1rH_6KwNYJ: — Our deploy process currently builds deploy artifacts and runs tests at the same time. I see how we could implement that using workflow via the 'parallel' step. However, we also want the behavior that if and when build-artifacts fails, it immediately cancels the running tests and fails the deploy job; and likewise if the tests fail, it immediately cancels the building of artifacts and fails the deploy job. If both succeed, then the deploy job continues. — This is a feature request to implement this sibling-cancel: with a flag (or perhaps as the default, though that's kinda scary), if one of the jobs in parallel() fails, then parallel cancels the other jobs. It sounds like parallel returns a map from job-label to job-status. I think under this behavior, the job-status would be "failed" for the job that failed, and "cancelled" for the sibling jobs that were cancelled. Environment: workflow plugin 1.1 Project: Jenkins Priority: Minor Reporter: Craig Silverstein 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.
