如果我跑步:
gcloud run jobs execute foo --project myproj --region us-central1 --format json
它为在云中生成的执行资源返回一个大而漂亮的数据结构。 无论执行最终是否失败,都会发生这种情况。
但是,如果我跑步:
gcloud run jobs execute foo --project myproj --region us-central1 --format json --wait
如果作业失败,我什么也得不到——只是将几行纯文本错误报告写入 STDERR。 没有任何结构可以让我编写工具。
X Creating execution... Task foo-8vn7q-task0 failed with message: The container exited with an error.
✓ Provisioning resources...
✓ Starting execution...
X Running execution... 0 / 1 complete
Executing job failed
ERROR: (gcloud.run.jobs.execute) The execution failed.
View details about this execution by running:
gcloud run jobs executions describe foo-8vn7q
Or visit https://console.cloud.google.com/run/jobs/executions/details/us-central1/foo-8vn7q/tasks?project=xxx
为什么? 等待更长时间应该会产生“更多”数据,而不是更少。 为什么 gcloud 会因为我等待而惩罚我? 为什么不仍然返回执行记录,而是记录失败状态? (事后 gcloud run jobs executions describe
产生相同的输出。)
describe
命令进行跟踪 - 如果该命令有
我可以使用 --wait
标志来阻止作业执行完成。 但事实并非如此。 这样就只剩下投票了。与此同时,我将让我的工具禁止执行 --wait
标志,以便完全避免这种情况。
--log-http
添加到
gcloud
命令,您将看到底层方法调用并更深入地了解命令的实现方式。有趣的是,gcloud run jobs
使用v1 API而不是v2。
当您gcloud run jobs execute
时,命令:
POST
namespaces.jobs.run
使用返回的 Execution
来获取
ObjectMeta
selfLink 使用自链接(反复)
namespaces.executions.get
更新了
Execution
的
Executions
的
ExecutionsStatus
的更新。不等待和等待(
--wait
)的区别在于:
不等待执行开始运行;和gcloud run jobs execute
的行为之前,您可以直接执行(例如
curl
)方法来实现您想要的行为,包括始终返回 Execution
。备注:
有一组
gcloud beta run jobs
gcloud
Operation
方法返回
projects.locations.jobs.run
,该方法与其他长时间运行的请求更好地保持一致。