artifact-manager-s3 seems to contain examples of most of the things needed. I did not quite understand...do you recommend against trying to do this or something else? If we would implement the same tests and use the same key as artifact-manager-s3, I would thing it would not be unreasonable work?
I figure if there is infrastructure now for this to work on s3 or azure, then just mapping it to a different directory should be pretty simple in my mind. Another way of doing this would be to just invest in lots of SSD storage for our jenkins servers... Might be cheaper if this would prove to be very complicated. On Friday, 30 November 2018 13:30:37 UTC+1, Daniel Beck wrote: > > > > > On 30. Nov 2018, at 10:40, Staffan Forsell <sta...@gmail.com > <javascript:>> wrote: > > > > Is there any obvious reasons that just creating a system property that > switches the artifacts to a different dir would not work? > > Given how many regressions the custom builds dir introduced due to moving > jobs between folders, renaming them, etc., and all those actions newly > having to be mirrored in a different structure, I'm not surprised nobody > bothered -- just having custom builds dir is good enough in many cases. > Would not recommend attempting it with using job names for the lookup. > > Would look at artifact-manager-s3 as a sort of template for custom > implementation for artifact storage. > > -- 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/5b9104a7-43b9-4980-b193-6c7a6b4d0cb1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
