Summary

Backend error: Exit status: 500, message: {"Type":"ExecutableNotFoundError","Message":"OCI runtime exec failed: exec failed: container_linux.go:349: starting container process caused \"exec: \\\"bash\\\": executable file not found in $PATH\": unknown","Handle":"","ProcessID":"","Binary":""}

Steps to reproduce

Use @vito buildkit container, or any container which doe

Spug运维平台在过去的公司里稳定运行3年以上，开源的大部分代码也是基于稳定版本之上，为了增加更多用户在企业使用的信心，如您愿意，请将您在企业中使用Spug的案例展示给我们，请在该issue页面提供您的使用案例，提交格式：企业名称 + 公司官网地址。官网地址为可选项，您可以直接提供企业名称即可。

此外，您也可以通过其他渠道如QQ、微信、邮件的方式联系项目作者提供使用案例。

征集长期有效，感谢大家支持！

Spug部分案例：

• 上海家谐网络科技有限公司
• 上海爱上慧家信息技术有限公司
• 南京白鸥网络技术有限公司
• 杭州中艺实业股份有限公司
• [北京步鼎方舟科技有限公司](http://

Summary

Right now Diffing Customization uses jsonPointers to indicate the patch to be ignored. This is sufficient when the tree contains non array objects. But, if an array is present, then it becomes infeasible to query the element to be ignored by array index. As such, support for jsonPath, which has the capability of making deeper queries, would go a long way.

Motivation

Cert M

Hi,

It seems like naming a remote is subject to certain limitations as groupadd is executed (potentially 32chars?).

Example

apiVersion: gitkube.sh/v1alpha1
kind: Remote
metadata:
  name: app-remote
  namespace: my-really-really-really-long-ns

k logs po/gitkub

External PRs does not pass the tests due to token autentication

 ● CML e2e › cml-send-comment

    Command failed: node ./bin/cml-send-comment.js comment.md
    Resource not accessible by integration

log here

What happened:

Join feature introduced "CREATED" status builds which is a holder build for storing intermediate status of upstream builds which can trigger this job. However UI shows "CREATED" as status for such events and users are able to nagigate to such builds and get confused on job's status.

What you expected to happen:

UI should ignore builds with CREATED status.
Users

https://github.com/google/starlark-go/blob/master/doc/spec.md

It should satisfy our reproducibility needs (like jsonnet) and could be easier to write agola config files.

Like in #137 we should provide build context information.