+dev@ -sz
On Feb 10, 2020, at 1:35 PM, Zha, Sheng <zhash...@amazon.com> wrote: As already stated in the public threads, I’ve vetoed the CodeBuild solution from becoming the long term solution as it’s not publicly manageable. As communicated before, the team should have put efforts in maintaining and fixing the Jenkins CD pipeline but has neglected to do so. Promoting the CodeBuild solution this way is a step in the wrong direction that has to be stopped. -sz On Feb 10, 2020, at 1:13 PM, Davydenko, Denis <d...@amazon.com> wrote: Hello guys, I would like to start this discussion so that we can align on handling CD pipelines we currently have. There are two of them: one in Jenkins<http://jenkins.mxnet-ci.amazon-ml.com/job/restricted-mxnet-cd/> and one in CodeBuild<https://tiny.amazon.com/1h49a01qg/IsenLink>. The one in Jenkins is currently functioning but its runs are always failing. The one in CodeBuild is currently functioning and publishing artifacts to S3 bucket<https://tiny.amazon.com/39negmk0/IsenLink>. MXNet Engineering team proposal is to shut down Jenkins based CD completely as it is currently just a waste of resources and use CodeBuild based setup to continue publishing nightly builds to S3 bucket, which provides public access to all binaries stored in it. This doesn’t affect a discussion of whether to publish binaries to S3 or to pypi – once that concludes (if ever) we can switch destination of CodeBuild projects so that they would upload MXNet nightly binaries to pypi instead of S3. This is an effort to get alignment internally, if possible, before bringing this as a proposal for community discussion. -- Thanks, Denis
