Replies: 4 comments 2 replies
-
在 build 这块
之前遗留下来的 fun 的 build 能力, 我个人感觉太多黑盒的东西 以这个为例, 甚至用了一个图来解释源码和交付物, 这个看起来是简化了用户的操作, 但是这个其实更多带来的是黑盒操作(如图列出来的 1,2,3,4):
其实我希望是这种模式:
|
Beta Was this translation helpful? Give feedback.
-
另外,build这里还需要注意: 我们还应该提供一个应用中心可以识别的能力,如果在应用中心--use-docker就会默认编程--use-local,这个可以通过环境变量来做。 关于镜像这里可能要在应用中心场景下单独看 |
Beta Was this translation helpful? Give feedback.
-
------------现有基础上优化
-------------高阶功能,必须要引导告诉用户的挂载目录等
-------------针对系统优化
-------------下一期支持cache |
Beta Was this translation helpful? Give feedback.
-
其中 sandbox 的语义, 是拉起 runtime 的 fc-docker build image, 然后将当前目录挂载到容器的 /code 目录, 当然 /code 目录里面可以跳转到映射到本地 codeuri 的目录, 然后可以执行自定义的命令, 在这里推荐两个命令:
|
Beta Was this translation helpful? Give feedback.
-
Build能力在Serverless架构下,是不可以忽略的功能,但是现在部分组件的build能力还是不足的。此处可以一起讨论一下,一个优秀的build组件应该具备哪些功能,以及我们后期要看齐的方向。
一个Build应该要具备三个层面的使用方法:
针对快速安装依赖/项目构建和:应该有用户提供相对应的文件(例如package.json,requirements.txt等),然后快速安装:
此时开发者如果进行构建,可以:
针对可以执行一些脚本安装一些内容:用户可以提供一个脚本,例如一个script.txt文件:
此时开发者如果进行构建,可以:
此时,系统不会自动去检测对应的依赖文件(例如package.json,requirements.txt等),而是选择执行脚本文件。
除了上面的部分,还可以给用户提供一个exec的能力,即
s build exec
,该方法是将当前的代码目录挂载到实例中,然后允许用户登录到实例进行处理。Beta Was this translation helpful? Give feedback.
All reactions