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.

Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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