Re: External Artifact Storage

[Liam Newman]

Re: Accepted status: 
I have a PR 76  pending merge 
that (among other things) clarifies the meaning of "Accepted" status.  

One of the key points is that review and acceptance should not be taken 
lightly.

By marking a JEP as "Accepted" the Reviewer indicates they believe that the 
JEP has 

clear scope, design completeness, community consensus, and (if applicable) 

in-progress implementation.  Without all of these a JEP cannot be accepted. 

For this reason, it is not unusual for JEPs to remain in "Draft" state even 
after 

they have strong community support and progressing implementation. They 

must still pass the other criteria, such as scoping and design 
completeness."


I hope this PR answers people's questions.  If it doesn't, I'd like to hear 
from them how to improve it.

Thanks,
-L.

 



On Friday, April 20, 2018 at 1:51:58 PM UTC-7, Kohsuke Kawaguchi wrote:
>
> This is a great effort that tackles a part of a broad problem space for 
> large scale / cloud native Jenkins users. My hats off to Carlos, Jesse, and 
> Oleg for driving these efforts. I've assigned Jesse as BDFL Delegate to 
> this JEP.
>
> For the future, a few nit pickings. I feel that the write-up of this JEP 
> mixes the core part and S3 specific part in one piece, which muddies water 
> a bit. For example, it reads "Core APIs already existed ..., but lacked the 
> crucial capability ... to provide a satisfactory S3 implementation," which 
> makes it sound like this change was needed to make S3 work, but really 
> AFAIK the core changes are aiming at all cloud blob stores, not just S3. I 
> also know Carlos and Jesse are focused on doing S3 as companion 
> implementation of this core change, but I also believe we welcome (and in 
> fact encourage) other people to do other cloud implementations, like Azure, 
> and there's nothing in the core changes that tie us to S3.
>
> I also think the amount of coding effort that went into this is well past 
> the criteria that I expect for "Accepted", if that's what led to Tyler's 
> commentary below, but I'm probably missing some context.
>
> So overall, for future JEPs in this space, it'd be good to get a JEP up a 
> little sooner so that we can overlap the time it takes for the actual 
> development and the consensus building.
>
> On Fri, Apr 20, 2018 at 9:37 AM R. Tyler Croy  > wrote:
>
>> (replies inline)
>>
>> On Fri, 13 Apr 2018, Carlos Sanchez wrote:
>>
>> > PR submitted at https://github.com/jenkinsci/jep/pull/83
>>
>>
>> Related to this work is this pull request which implements extensions to
>> VirtualFile, which I would consider very key to this work:
>> https://github.com/jenkinsci/jenkins/pull/3302
>>
>> With that pull request there have been some questions raised about how 
>> the JEP
>> Workflow interacts with the implementation workflow, and merging of code 
>> into
>> plugin and core repositories. I wanted to share the expectations I had in 
>> mind
>> when bringing over parts of PEP into JEP-1.
>>
>> The workflow for a Standards JEP is generally going to be 
>> Draft->Accepted[0]->Final[1]
>>
>> JEP-1 is somewhat intentionally vague on how these map to merges of pull
>> requests and APIs. My original thoughts around this were that this would 
>> be a
>> good thing and allow us the most flexibility in writing code alongside
>> discussing design and APIs, depending on the repository and design. I 
>> recognize
>> how this ambiguity also leaves room for confusion.
>>
>>
>> Working backwards, Final is the most clear and obvious in my opinion. A 
>> JEP
>> marked as Final means designs and APIs are merged, finalized, and 
>> considered
>> "supported" for whatever our hand-wavey-API-support-policy is (i.e. public
>> APIs) in whatever project they're being merged.
>>
>> The requirements for implementation around Accepted[0] much more loosely
>> defined as:
>>
>> "The proposed implementation, if applicable, must be solid, must not 
>> complicate
>> Jenkins unduly, and must be the same license as the component the 
>> proposal is
>> meant to added to"
>>
>> In the case of Jenkins Essentials, we're merging code regardless of 
>> Accepted,
>> or even Draft JEP status, because obviously, that's most expedient given 
>> the
>> state of that project.
>>
>> In the case of Jenkins plugins and core which are already being used, I
>> understand that is not the case. However, I think it would be a failure 
>> for JEP
>> if we are reluctant to merge code and make _use_ of it before the 
>> "Accepted" or
>> "Final" states are reached.
>>
>> To a certain extent I believe that no API or design can be safely 
>> considered
>> Final without real world experimental or beta usage.  Hiding something 
>> behind a
>> feature flag, or a @Beta annotation, for core or plugins is (IMHO) a 
>> really
>> good thing to strive for even in the Draft stage to get _real_ usage of 
>> designs
>> in the hands of testers and users. 

Re: External Artifact Storage

[Kohsuke Kawaguchi]

This is a great effort that tackles a part of a broad problem space for
large scale / cloud native Jenkins users. My hats off to Carlos, Jesse, and
Oleg for driving these efforts. I've assigned Jesse as BDFL Delegate to
this JEP.

For the future, a few nit pickings. I feel that the write-up of this JEP
mixes the core part and S3 specific part in one piece, which muddies water
a bit. For example, it reads "Core APIs already existed ..., but lacked the
crucial capability ... to provide a satisfactory S3 implementation," which
makes it sound like this change was needed to make S3 work, but really
AFAIK the core changes are aiming at all cloud blob stores, not just S3. I
also know Carlos and Jesse are focused on doing S3 as companion
implementation of this core change, but I also believe we welcome (and in
fact encourage) other people to do other cloud implementations, like Azure,
and there's nothing in the core changes that tie us to S3.

I also think the amount of coding effort that went into this is well past
the criteria that I expect for "Accepted", if that's what led to Tyler's
commentary below, but I'm probably missing some context.

So overall, for future JEPs in this space, it'd be good to get a JEP up a
little sooner so that we can overlap the time it takes for the actual
development and the consensus building.

On Fri, Apr 20, 2018 at 9:37 AM R. Tyler Croy  wrote:

> (replies inline)
>
> On Fri, 13 Apr 2018, Carlos Sanchez wrote:
>
> > PR submitted at https://github.com/jenkinsci/jep/pull/83
>
>
> Related to this work is this pull request which implements extensions to
> VirtualFile, which I would consider very key to this work:
> https://github.com/jenkinsci/jenkins/pull/3302
>
> With that pull request there have been some questions raised about how the
> JEP
> Workflow interacts with the implementation workflow, and merging of code
> into
> plugin and core repositories. I wanted to share the expectations I had in
> mind
> when bringing over parts of PEP into JEP-1.
>
> The workflow for a Standards JEP is generally going to be
> Draft->Accepted[0]->Final[1]
>
> JEP-1 is somewhat intentionally vague on how these map to merges of pull
> requests and APIs. My original thoughts around this were that this would
> be a
> good thing and allow us the most flexibility in writing code alongside
> discussing design and APIs, depending on the repository and design. I
> recognize
> how this ambiguity also leaves room for confusion.
>
>
> Working backwards, Final is the most clear and obvious in my opinion. A JEP
> marked as Final means designs and APIs are merged, finalized, and
> considered
> "supported" for whatever our hand-wavey-API-support-policy is (i.e. public
> APIs) in whatever project they're being merged.
>
> The requirements for implementation around Accepted[0] much more loosely
> defined as:
>
> "The proposed implementation, if applicable, must be solid, must not
> complicate
> Jenkins unduly, and must be the same license as the component the
> proposal is
> meant to added to"
>
> In the case of Jenkins Essentials, we're merging code regardless of
> Accepted,
> or even Draft JEP status, because obviously, that's most expedient given
> the
> state of that project.
>
> In the case of Jenkins plugins and core which are already being used, I
> understand that is not the case. However, I think it would be a failure
> for JEP
> if we are reluctant to merge code and make _use_ of it before the
> "Accepted" or
> "Final" states are reached.
>
> To a certain extent I believe that no API or design can be safely
> considered
> Final without real world experimental or beta usage.  Hiding something
> behind a
> feature flag, or a @Beta annotation, for core or plugins is (IMHO) a really
> good thing to strive for even in the Draft stage to get _real_ usage of
> designs
> in the hands of testers and users. All the while, still communicating our
> intention that these are *beta* (not in the Google sense).
>
> The quote "No plan survives contact with the enemy", and my favorite Mike
> Tyson
> derivative "Everybody has a plan until they get punched in the mouth" come
> to
> mind :)
>
>
> With regards to the pull request for Jenkins core above, my recommendation
> for
> the folks working on core is to merge and ship designed, documented, and
> clearly marked Beta APIs which do not unduly complicate Jenkins, and of
> course
> can be safely released and exercised in weekly and LTS releases. I think
> plugins should be encouraged to follow similar guidelines at their
> maintainers' discretion.
>
>
> Optimizing for safely trying new things in released versions of code is
> IMHO a
> very good thing.
>
>
>
> Cheers
>
>
>
> [0] https://github.com/jenkinsci/jep/tree/master/jep/1#accepted
> [1] https://github.com/jenkinsci/jep/tree/master/jep/1#finalizing-a-jep
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe 

Re: External Artifact Storage

[R. Tyler Croy]

(replies inline)

On Fri, 13 Apr 2018, Carlos Sanchez wrote:

> PR submitted at https://github.com/jenkinsci/jep/pull/83


Related to this work is this pull request which implements extensions to
VirtualFile, which I would consider very key to this work:
https://github.com/jenkinsci/jenkins/pull/3302

With that pull request there have been some questions raised about how the JEP
Workflow interacts with the implementation workflow, and merging of code into
plugin and core repositories. I wanted to share the expectations I had in mind
when bringing over parts of PEP into JEP-1.

The workflow for a Standards JEP is generally going to be 
Draft->Accepted[0]->Final[1]

JEP-1 is somewhat intentionally vague on how these map to merges of pull
requests and APIs. My original thoughts around this were that this would be a
good thing and allow us the most flexibility in writing code alongside
discussing design and APIs, depending on the repository and design. I recognize
how this ambiguity also leaves room for confusion.


Working backwards, Final is the most clear and obvious in my opinion. A JEP
marked as Final means designs and APIs are merged, finalized, and considered
"supported" for whatever our hand-wavey-API-support-policy is (i.e. public
APIs) in whatever project they're being merged.

The requirements for implementation around Accepted[0] much more loosely
defined as:

"The proposed implementation, if applicable, must be solid, must not 
complicate
Jenkins unduly, and must be the same license as the component the proposal 
is
meant to added to"

In the case of Jenkins Essentials, we're merging code regardless of Accepted,
or even Draft JEP status, because obviously, that's most expedient given the
state of that project.

In the case of Jenkins plugins and core which are already being used, I
understand that is not the case. However, I think it would be a failure for JEP
if we are reluctant to merge code and make _use_ of it before the "Accepted" or
"Final" states are reached.

To a certain extent I believe that no API or design can be safely considered
Final without real world experimental or beta usage.  Hiding something behind a
feature flag, or a @Beta annotation, for core or plugins is (IMHO) a really
good thing to strive for even in the Draft stage to get _real_ usage of designs
in the hands of testers and users. All the while, still communicating our
intention that these are *beta* (not in the Google sense).

The quote "No plan survives contact with the enemy", and my favorite Mike Tyson
derivative "Everybody has a plan until they get punched in the mouth" come to
mind :)


With regards to the pull request for Jenkins core above, my recommendation for
the folks working on core is to merge and ship designed, documented, and
clearly marked Beta APIs which do not unduly complicate Jenkins, and of course
can be safely released and exercised in weekly and LTS releases. I think
plugins should be encouraged to follow similar guidelines at their
maintainers' discretion.


Optimizing for safely trying new things in released versions of code is IMHO a
very good thing.



Cheers



[0] https://github.com/jenkinsci/jep/tree/master/jep/1#accepted
[1] https://github.com/jenkinsci/jep/tree/master/jep/1#finalizing-a-jep

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/20180420163747.GF1836%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: External Artifact Storage

[Baptiste Mathus]

Posted a small comment/request for clarification on the merged PR, but
otherwise LGTM.

2018-04-13 17:38 GMT+02:00 Carlos Sanchez :

> PR submitted at https://github.com/jenkinsci/jep/pull/83
>
> On Fri, Apr 13, 2018 at 5:24 PM, Oleg Nenashev 
> wrote:
>
>> Looks good to me **as a DRAFT**.
>> Please propose a pull request so that JEP editors can review it.
>>
>> We also need somebody to be selected as BDFL Delegate if KK is not
>> available to review it.
>>
>> BR, Oleg
>>
>>
>> On Friday, April 13, 2018 at 4:25:38 AM UTC+2, Jesse Glick wrote:
>>>
>>> +1
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/jenkinsci-dev/0851cc7d-d3cc-4da9-8a76-b841817e38da%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/CALHFn6P6vQxzVXmLLQnff7CFeOTYbC6aF7OmM-KVBM%2BXwGPbjg%
> 40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7BWNgaYiwAD8_UQEQUbFrEoBwu0XusET6x8Ebv3r0PvQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins External Artifact Storage core changes in LTS

[Carlos Sanchez]

On Mon, Apr 16, 2018 at 9:32 AM, Oliver Gondža  wrote:

> Thanks for the details, guys. I have rechecked all new API is annotated
> with Beta. I am wondering, what plugins are going to consume this? I am
> trying to understand what userbase will be exposed to the change, what use
> cases can be affected.
>

To be clear, this would be for the next LTS picked in May, not for the
current in progress one.

Existing artifact manager usage is unaffected, everything continues to work
as before storing things on disk.
Only when the new plugin implementing the artifact manager for s3 is
enabled artifacts would go to S3

https://github.com/jenkinsci/jep/blob/master/jep/202/README.adoc#prototype-
implementation

The new one is artifact-manager-s3-plugin


Related PRs

   -

   JENKINS-26810  File
   attribute/symlink support in VirtualFile - fixed as a side effect
   -

   JENKINS-49635  Permit
   VirtualFile to serve external file contents
   -

   Jenkins core PR-3302 
   -

   WAR packaging implementation for the reference implementation
   

Downstream improvements to use the new APIs

   -

   workflow-api-plugin PR-67
   
   -

   workflow-basic-steps-plugin PR-60
   
   -

   copyartifact-plugin PR-100
   
   -

   compress-artifacts-plugin PR-1
   




>
> Having said that, I see this backportable into .3 provided it will be
> merged by the end of the backporting window. Also, It would be great if you
> can either provide ATH tests for the new plugin functionality for RC
> testing window or retest and report during that window.


> Thanks!
> --
> oliver
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/jenkinsci-dev/9760335c-57cd-0d30-cc90-0053107cfbcb%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CALHFn6MTY1qEH4uQhdr0%2BoA7rsHKU4AxFhaz3MjtQ%3DOg%2BbLirw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins External Artifact Storage core changes in LTS

[Oliver Gondža]

Thanks for the details, guys. I have rechecked all new API is annotated 
with Beta. I am wondering, what plugins are going to consume this? I am 
trying to understand what userbase will be exposed to the change, what 
use cases can be affected.


Having said that, I see this backportable into .3 provided it will be 
merged by the end of the backporting window. Also, It would be great if 
you can either provide ATH tests for the new plugin functionality for RC 
testing window or retest and report during that window.


Thanks!
--
oliver

--
You received this message because you are subscribed to the Google Groups "Jenkins 
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/9760335c-57cd-0d30-cc90-0053107cfbcb%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins External Artifact Storage core changes in LTS

[Carlos Sanchez]

On Fri, Apr 13, 2018, 22:08 R. Tyler Croy  wrote:

> (replies inline)
>
> On Fri, 13 Apr 2018, Oliver Gond??a wrote:
>
> > On 2018-04-13 18:23, Carlos Sanchez wrote:
> > > Hi Oliver,
> > >
> > > There are some changes for core that would be really helpful to have in
> > > hands of people for testing sooner than later
> > >
> > > https://github.com/jenkinsci/jenkins/pull/3302
> > >
> > > All new methods are marked with the new @Beta annotation so it should
> be
> > > clear that it's not final.
> > >
> > > We expect this to be in the next weekly or so,but I would really like
> to
> > > ensure we can pull this into the next LTS if at all possible,what can I
> > > do to help prepare these changes for the LTS,even if we tried to
> > > backport it?
> >
> > Hi, Let's make the discussion public.
> >
> > My personal take is the LTS and Beta.class are quite orthogonal in
> > principle. When it comes to the actual change, it feels far from trivial
> for
> > such an exception IMO. What is the motivation here? Backporting this will
> > get it in LTS in 4 weeks, otherwise it will get in in 8 weeks.
> >
> > Thoughts? I would really like to avoid backporting something before it
> has
> > its final shape (IOW, merged to master).
>
>
> Hey Oliver, I was chatting with Carlos about this earlier and encouraged
> him to
> reach out to you to better understand your thoughts for considering code
> coming
> into the LTS.
>
> From my understanding of what Carlos is asking about, is not pulling
> anything
> into an LTS which isn't already in a Weekly release. Rather, I think
> Carlos is
> apprehensive about the timing between Weekly releases and LTS, and is
> worried
> about missing the last Weekly before our typical 2-weeks-before LTS
> cutoff."
>
> I think Carlos's team has worked quite hard to get the underlying code to
> enable external artifacts ready, and considers one indication of "success"
> to
> have that code delivered in our next LTS cycle, since LTSes are consumed
> by the
> vast majority of Jenkins users who would benefit from this functionality.
>


Tyler has summarized it correctly, I expect this to be in master soon but
just want to make sure we don't miss the LTS.

Getting useful feedback and having final implementations ready in the
future for this type of change relies on putting this in the hands of as
many people as possible.

That's why the API changes use @beta annotations (and I believe we would be
the first ones using it), to get new functionality in the hands of users
asap, improve the velocity of new feature delivery while ensuring that
stability is not affected.

Cheers




>
> I *hope* I've captured the situation clearly.
>
>
> The questions Carlos has about LTS timing I think are all moot assuming
> that
> the aforementioned pull request gets reviewed and merged in a timely
> manner for
> next week's release (from my understanding).
>
>
>
> Cheers
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CALHFn6NF_gvKf955%3DAcPfunkbO%2BfaqwbuYMM0EMgO_QVumKUSw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins External Artifact Storage core changes in LTS

[R. Tyler Croy]

(replies inline)

On Fri, 13 Apr 2018, Oliver Gond??a wrote:

> On 2018-04-13 18:23, Carlos Sanchez wrote:
> > Hi Oliver,
> > 
> > There are some changes for core that would be really helpful to have in
> > hands of people for testing sooner than later
> > 
> > https://github.com/jenkinsci/jenkins/pull/3302
> > 
> > All new methods are marked with the new @Beta annotation so it should be
> > clear that it's not final.
> > 
> > We expect this to be in the next weekly or so,but I would really like to
> > ensure we can pull this into the next LTS if at all possible,what can I
> > do to help prepare these changes for the LTS,even if we tried to
> > backport it?
> 
> Hi, Let's make the discussion public.
> 
> My personal take is the LTS and Beta.class are quite orthogonal in
> principle. When it comes to the actual change, it feels far from trivial for
> such an exception IMO. What is the motivation here? Backporting this will
> get it in LTS in 4 weeks, otherwise it will get in in 8 weeks.
> 
> Thoughts? I would really like to avoid backporting something before it has
> its final shape (IOW, merged to master).


Hey Oliver, I was chatting with Carlos about this earlier and encouraged him to
reach out to you to better understand your thoughts for considering code coming
into the LTS.

>From my understanding of what Carlos is asking about, is not pulling anything
into an LTS which isn't already in a Weekly release. Rather, I think Carlos is
apprehensive about the timing between Weekly releases and LTS, and is worried
about missing the last Weekly before our typical 2-weeks-before LTS cutoff."

I think Carlos's team has worked quite hard to get the underlying code to
enable external artifacts ready, and considers one indication of "success" to
have that code delivered in our next LTS cycle, since LTSes are consumed by the
vast majority of Jenkins users who would benefit from this functionality.


I *hope* I've captured the situation clearly.


The questions Carlos has about LTS timing I think are all moot assuming that
the aforementioned pull request gets reviewed and merged in a timely manner for
next week's release (from my understanding).



Cheers

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/20180413200804.GD1836%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Jenkins External Artifact Storage core changes in LTS

[Oliver Gondža]

On 2018-04-13 18:23, Carlos Sanchez wrote:

Hi Oliver,

There are some changes for core that would be really helpful to have in 
hands of people for testing sooner than later


https://github.com/jenkinsci/jenkins/pull/3302

All new methods are marked with the new @Beta annotation so it should be 
clear that it's not final.


We expect this to be in the next weekly or so,but I would really like to 
ensure we can pull this into the next LTS if at all possible,what can I 
do to help prepare these changes for the LTS,even if we tried to 
backport it?


Hi, Let's make the discussion public.

My personal take is the LTS and Beta.class are quite orthogonal in 
principle. When it comes to the actual change, it feels far from trivial 
for such an exception IMO. What is the motivation here? Backporting this 
will get it in LTS in 4 weeks, otherwise it will get in in 8 weeks.


Thoughts? I would really like to avoid backporting something before it 
has its final shape (IOW, merged to master).

--
oliver

--
You received this message because you are subscribed to the Google Groups "Jenkins 
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/3b119729-f2a5-f3ac-a217-16a90a26e426%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: External Artifact Storage

[Carlos Sanchez]

PR submitted at https://github.com/jenkinsci/jep/pull/83

On Fri, Apr 13, 2018 at 5:24 PM, Oleg Nenashev 
wrote:

> Looks good to me **as a DRAFT**.
> Please propose a pull request so that JEP editors can review it.
>
> We also need somebody to be selected as BDFL Delegate if KK is not
> available to review it.
>
> BR, Oleg
>
>
> On Friday, April 13, 2018 at 4:25:38 AM UTC+2, Jesse Glick wrote:
>>
>> +1
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/0851cc7d-d3cc-4da9-8a76-b841817e38da%
> 40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CALHFn6P6vQxzVXmLLQnff7CFeOTYbC6aF7OmM-KVBM%2BXwGPbjg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: External Artifact Storage

[Oleg Nenashev]

Looks good to me **as a DRAFT**.
Please propose a pull request so that JEP editors can review it.

We also need somebody to be selected as BDFL Delegate if KK is not 
available to review it.

BR, Oleg


On Friday, April 13, 2018 at 4:25:38 AM UTC+2, Jesse Glick wrote:
>
> +1 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/0851cc7d-d3cc-4da9-8a76-b841817e38da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: External Artifact Storage

[Jesse Glick]

+1

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0HczAc%2BkY0FkzjTpwBtVqaqKCNwkcCiKyDEVojieroHA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

External Artifact Storage

[Carlos Sanchez]

Hi there,

With the goal to make Jenkins more "cloud-friendly" or "cloud-native" I
have created a JEP draft to enable the storage of artifacts outside the
Jenkins home, ready for review

https://github.com/carlossg/jep/tree/jep-submission/jep/

TL;DR

Adding an ArtifactManager implementation (with required core changes) that
transparently stores artifacts in a external blob store / artifact
repository. First implementation using AWS S3

Please share your feedback

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CALHFn6Pqc_1CCzqJcLsqmA62uEwsn4pvkFpYR9K0Hp6-ygPc_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.