Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

render: label the Docker containers and networks render creates

Open
  • Is something wrong?
#401 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
docker, go
Domain
cli, devops

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Go
Stars
19
Forks
33
Avg merge
3d 4h
Merged PRs (30d)
40

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from crossplane/cli

All issues in crossplane/cli

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.