Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

render: label the Docker containers and networks render creates

已关闭
  • 哪里不对？
#401 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 3 天内回复

@jcogilvie 已经在做这个了。

开始于 2026年10月1日。

  • #407 来自 @jcogilvie —— 未关闭

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
docker, go
领域
cli, devops

调研方向

Start by tracing RuntimeDocker.createContainer, the Docker engine's render container creation, and createRenderNetwork. Read the existing cleanup-policy handling and follow how render sessions and networks are created and removed; done means every render-owned container and network carries consistent identifying labels without changing existing cleanup behavior.

由索引模型根据 Issue 内容生成。

描述

enhancement
What problem are you facing?

There's no reliable way to tell which Docker containers and networks were created by crossplane render, so
anything it leaves behind can't be found and cleaned up afterwards.

Today the containers render creates carry only the image's own io.crossplane.xpkg:* label, unnamed
Function containers get random Docker names (suspicious_newton, distracted_mestorf, …), and the
crossplane internal render engine container and the crossplane-render-* network carry no labels at all.
Matching by image or name prefix is guesswork, and can catch containers the user started on purpose.

This matters because leftovers happen:

  • Some interruptions can never be cleaned up in-process: kill -9, a crash, an OOM kill, a CI job timeout.
    Even with signal handling (#400), these leave resources behind.
  • Containers deliberately kept with runtime-docker-cleanup: Orphan or runtime-docker-name (for warm
    reuse across invocations) build up over time and can't be told apart from accidental leaks.
  • Tools built on the render library — for example
    crossplane-diff, which renders many times per run —
    have the same problem and currently have to track container names themselves.
How could Crossplane help solve your problem?

Add labels to every container and network render creates (in RuntimeDocker.createContainer, the docker
engine's render container, and createRenderNetwork). For example:

Label Value Purpose
render.crossplane.io/managed-by crossplane Identifies render-owned resources
render.crossplane.io/session per-invocation ID Scopes cleanup to one run
render.crossplane.io/cleanup the effective cleanup policy (Remove, Stop, Orphan) Lets a sweep skip containers the user deliberately kept
render.crossplane.io/created-by-pid (optional) PID Helps detect leftovers from dead sessions

That enables:

  • A plain docker ps -a --filter label=render.crossplane.io/managed-by=crossplane for users.
  • Optionally, a small subcommand (e.g. crossplane render cleanup [--all]) that removes leftovers from dead
    sessions, skipping containers kept with Orphan/runtime-docker-name unless --all is given.
  • Safer network cleanup: before removing a network, render could force-remove containers from its own
    session that are still attached, without touching unrelated containers on a user-supplied
    --crossplane-docker-network (see #398).
  • Library consumers could clean up by label and session ID instead of tracking container names themselves.

Adding labels is purely additive and doesn't change behaviour for existing users.

主要语言
Go
星标
20
派生
34
平均合并
5 天 4 小时
30 天内合并 PR
21

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

crossplane/cli 的其他 Issue

查看 crossplane/cli 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。