Hi Marco, I've taken up the task to fix the CD pipeline [1] and it's pending CI checks and merge. I also made the adjustments to the namespace layout of the mxnet s3 bucket and updated the static page which is now accessible from https://repo.mxnet.io/dist/index.html.
Meanwhile, the access from the CodeBuild to publish to the mxnet s3 bucket has been revoked so its status should no longer be relevant. I will update the installation doc to reflect only the artifacts published by Jenkins CD. I hope this brings conclusion to this situation. Let me know if there's any further question. -sz [1] https://github.com/apache/incubator-mxnet/pull/17551 On 2020/02/10 23:57:47, Marco de Abreu <marco.g.ab...@gmail.com> wrote: > Thanks for bringing this to our attention. > > I'm quite devastated that our two vetoes have been ignored and the > CodeBuild pipeline is actually supplying our user-facing binaries. > Suggesting to turn of the Jenkins based CD now adds insult to injury. > > I'd like to hear a plan how to make the project compliant again. I already > announced that I will remove any mentions of that publishing method (speak, > all links on our website pointing to the bucket) if the sourcing system is > not our Jenkins CD. So far I believed that this was actually done, but > seems like we got played here. > > For the sake of our users, I'm giving one week (until 2/17) to come up with > a proposal and until the end of the month 2/29 to have CodeBuild turned off > and Jenkins CD fixed. Considering we have been tricked last time, I want to > have confirmation that CodeBuild has been turned off and a description how > we can verify that all artifacts are now coming from Jenkins CD. > > Best regards > Marco > > Zha, Sheng <zhash...@amazon.com.invalid> schrieb am Mo., 10. Feb. 2020, > 19:40: > > > +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 > > >
