Yeah I think that's essentially what I'm thinking. That's great. So the
JIRA issue covers the fact that the retrieval side of things is not
currently abstracted away and relies on physical file paths? Means that
the CopyArtifact plugin wouldn't correctly work with a different artifact
On Tue, Jun 16, 2015 at 11:34 AM, Matthew mitchell
mmitche.match...@gmail.com wrote:
So the JIRA issue covers the fact that the retrieval side of things is not
currently abstracted away and relies on physical file paths?
No, the retrieval is abstracted, but the current abstraction still
On Wed, 17 Jun 2015 at 04:50 Jesse Glick jgl...@cloudbees.com wrote:
So the JIRA issue covers the fact that the retrieval side of things is
not
currently abstracted away and relies on physical file paths?
No, the retrieval is abstracted, but the current abstraction still
requires the
Yeah we have a lot of network traffic on our Jenkins (the .NET foundation
CI) and it would be preferable to offload it from the master.
Does that work item cover the content delivery channel?
On Tuesday, June 16, 2015 at 1:50:46 PM UTC-7, Richard Bywater wrote:
On Wed, 17 Jun 2015 at 04:50
Just to reply to my own email to clarify my previous statement:
In some cases [routing everything through the master node] might be
preferable depending on your network setup. For instance, its a much easier
sell to get firewall / proxy configurations for single servers and not a
multitude of
On Tue, Jun 16, 2015 at 8:52 PM, Richard Bywater rich...@byh2o.com wrote:
In some cases [routing everything through the master node] might be
preferable depending on your network setup. For instance, its a much easier
sell to get firewall / proxy configurations for single servers and not a
On Mon, Jun 15, 2015 at 12:35 PM, Matthew mitchell
mmitche.match...@gmail.com wrote:
Has any thought been given to abstracting away the artifact storage? Not
necessarily meaning that the existing uploaders would go away or be
replaced, but that the standard artifact uploading would abstract
