[ https://issues.apache.org/jira/browse/OOZIE-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16502065#comment-16502065 ]
Robert Kanter commented on OOZIE-2877: -------------------------------------- Makes sense to me then. Let's stick with the original credential handling. [~pbacsko] makes a good point. We shouldn't be fetching a remote repo during a unit test. Perhaps JGit has some easy way of mocking this or doing it locally? > Oozie Git Action > ---------------- > > Key: OOZIE-2877 > URL: https://issues.apache.org/jira/browse/OOZIE-2877 > Project: Oozie > Issue Type: Sub-task > Components: action > Reporter: Clay B. > Assignee: Clay B. > Priority: Major > Labels: action > Fix For: trunk > > Attachments: 0001-OOZIE-2877-Oozie-Git-Action.patch, > 0002-OOZIE-2877-Oozie-Git-Action.patch, > 0003-OOZIE-2877-Oozie-Git-Action.patch, > 0004-OOZIE-2877-Oozie-Git-Action.patch, > 0005-OOZIE-2877-Oozie-Git-Action.patch, > 0006-OOZIE-2877-Oozie-Git-Action.patch, > 0007-OOZIE-2877-Oozie-Git-Action.patch, > 0008-OOZIE-2877-Oozie-Git-Action.patch, > 0009-OOZIE-2877-Oozie-Git-Action.patch, OOZIE-2877.010.patch, > OOZIE-2877.011.patch, OOZIE-2877.012.patch > > > To aide in deploying ASCII artifacts to clusters, let's provide a tie-in for > a source-code management system. Git would be my preferred choice. > Ideally, this could handle a user's key material e.g. for an ssh key to pull > down from a secured repository. This would free users from handling their own > key staging and clean-up on YARN nodes and only require them to store the key > secured in HDFS. -- This message was sent by Atlassian JIRA (v7.6.3#76005)