nodejs / nodejs/docker-node

PRs updates may cause unwanted PR creation in `docker-library/official-images`

Open Beginner friendly
#2,564 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

build process docs
Dominant language
Dockerfile
Stars
8.6k
Forks
2k
Avg merge
10h 19m
Merged PRs (30d)
16

Description

Situation

When Dockerfile-template.* changes are made and Dockerfile updates in the release line directories are also made, then the repo automatically triggers a PR to build a new release. The workflow official-pr is responsible for this.

Unless the update is part of a new release, then Dockerfile updates should generally not be done manually. These updates should be left to the automated processes that are triggered when the repo's automatic-updates.yml polling workflow detects a new Node.js release.

Suggestion

Research the background and add instructions to the CONTRIBUTING document about when Dockerfile updates should be made directly, and when it should be left to automation.

For those cases where no direct Dockerfile update should be included in a PR, describe also how to test such PRs.

Contributor guide

Open the contributing guide

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.

Research direction

Read CONTRIBUTING.md alongside .github/workflows/official-pr.yml and automatic-updates.yml to understand when Dockerfile changes trigger official-image pull requests. Update CONTRIBUTING.md with the direct-update exceptions and instructions for testing PRs that should not include a Dockerfile update; done means both cases are clearly documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, dockerfile, github-actions
Domain
ci-cd, documentation
Issue type
Documentation
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.