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 >
