Expand builds-and-runs docs to clarify tag behavior across versions
Los mantenedores suelen responder en 1 día
@TC-MO ya está trabajando en esto.
Desde el 26/5/2026.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
Reported on Slack: tag behavior on Actor builds is documented in fragments, with no single place explaining the full picture. Users hit confusing edge cases:
- Two builds across different versions can share the same tag name (e.g., both
0.0and0.1taggedlatest). When the Actor runs, it picks whichever was built last. - The auto-tagging dialog reinforces the impression that tags are version-specific, when in practice the effective build for a tag is whichever was built and tagged most recently.
Current docs only state that tags are exclusive across all builds and versions, and that they move when another build is tagged the same.
They do not explain:
- That tags can be set on builds via the Console UI and via the API (not only at build time).
- How build numbers are constructed from
MAJOR.MINORby appending.BUILD. - That multiple versions can in theory share the same tag, that each new build overrides the tag, and that this is not practical, so different tags should be used for different versions.
Proposed changes
Expand https://docs.apify.com/platform/actors/development/builds-and-runs/builds#tags to:
- Document that tags can be set on existing builds through the Console UI and via the API, not only during build creation.
- In the Versioning section, explain build number construction (
MAJOR.MINOR.BUILD). - Add an explicit note that multiple versions can technically share the same tag, that each build overrides the tag, and that this is not a recommended pattern. Recommend distinct tags per version.
- Lenguaje dominante
- JavaScript
- Estrellas
- 82
- Forks
- 240
- Merge medio
- 4 d 3 h
- PR fusionados (30 d)
- 40
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de apify/apify-docs
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
apify/apify-docs#3071 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
apify/apify-docs#3049 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
apify/apify-docs#2742 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 82/100
apify/apify-docs#2741 ·
Los mantenedores suelen responder en 1 día
-
low priority t-unblocking tech enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
apify/apify-docs#2451 ·
Los mantenedores suelen responder en 1 día
Todos los issues de apify/apify-docs
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 2 días
-
good first issue
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
saayam-for-all/webapp#1919 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Uuriko/project-room#3728 ·
Los mantenedores suelen responder en 1 día
-
factory-active task-identify-harness-labels-done task-identify-issue-type-done
Dificultad 1/5 Menos de una hora Aptitud para principiantes 70/100
vercel/ai#23435 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
docs(site): Mermaid edge-label contrast on Architecture and a table header on How it comparesAbiertodocumentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
devops-thiago/ThrillhouseBot#1132 ·
Los mantenedores suelen responder en 1 día