areusch commented on PR #11809: URL: https://github.com/apache/tvm/pull/11809#issuecomment-1179106048
i think most of the discussion here has aligned around purpose-built CI images. @leandron are your concerns assuaged? regarding `ci_base`: I'm somewhat supportive of this, but currently unsure whether this would move the needle very much in practice and there are some operational concerns. we currently build images mostly automatically around the same time via the nightly rebuild and also in CI. the common deps we're talking about here are mostly a mix of `apt` packages plus some things built from sources downloaded from (i think) version-pinned URLs. there are some other things in here, to be sure--rust packages, for instance. i do agree that `ci_base` would enforce that we don't diverge, but just stating that i don't know, given the above, that i expect to see a huge effect in creating that. i agree with @Mousius that the layers would ideally be reused; i wouldn't underestimate the network transfer time, however. I do want to note that we also mitigate drift in other was e.g. via common install scripts and (soon) via locked python dependencies (this more addresses the example of tensorflow divergence). however, i acknowledge the drawback that this is merely convention and dependent on reviewers. for verticals like microTVM, i think a separate image makes sense. for e.g. backends, it's less clear--what if you want to test cuda with paddlepaddle? there is no such paddlepaddle dep for arm64, so it can't go in the base image. does this mean base images need to be arch-specific--if so, where's the line (e.g. what if it's available for 20.04 but not 18.04)? so far as action items, i think we should capture the need of either a common base image or documentation into a GH issue. we should also update our docs accordingly. would love to hear more thoughts @Mousius @manupa-arm @leandron @driazati -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
