Skip to content

Dockerfile best practices: clarify behavior of pipefail in RUN steps #11427

Open
@rvsasseen

Description

@rvsasseen

File: develop/develop-images/dockerfile_best-practices.md

Please consider clarifying whether the pipefail option set by "RUN set -o pipefail &&" carries over to subsequent RUN commands. In a bash script the pipefail setting would carry over to subsequent commands, but it's not clear to me whether it would in a Dockerfile. I would guess maybe the answer is no because no files are affected by the setting and so there's nothing in the resulting layer that preserves the setting.

By the same token, would it work just to "RUN set -o pipefail" once and have it carry over to subsequent RUN commands, or is that not possible.

Activity

changed the title pipefail clarification Dockerfile best practices: clarify behavior of pipefail in RUN steps on Dec 2, 2020
added
area/buildRelates to Dockerfiles or docker build command
on Dec 2, 2020
thaJeztah

thaJeztah commented on Dec 2, 2020

@thaJeztah
Member

Thanks for reporting; the set -o won't be inherited by following RUN steps. Each RUN runs in a new container, and because of that, changes that are only present in memory (like set, but also (e.g.) export SOMEVAR=somevalue) are not persisted. Changes that are made to the filesystem on the other hand are persisted, so would be available in RUN steps after that.

I agree that this may need to be explained better (contributions welcome); perhaps also in the Dockerfile reference; https://docs.docker.com/engine/reference/builder/#run (that file is maintained in the CLI repository though, so would need a separate pull request; https://github.com/docker/cli/blob/master/docs/reference/builder.md)

docker-robot

docker-robot commented on Nov 23, 2023

@docker-robot

There hasn't been any activity on this issue for a long time.
If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale comment.
If not, this issue will be closed in 14 days. This helps our maintainers focus on the active issues.

Prevent issues from auto-closing with a /lifecycle frozen comment.

/lifecycle stale

docker-robot

docker-robot commented on Jan 6, 2024

@docker-robot

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

/lifecycle locked

locked and limited conversation to collaborators on Jan 6, 2024
thaJeztah

thaJeztah commented on Jan 6, 2024

@thaJeztah
Member

Looks like this closed before being improved; let me mark it as "frozen"

unlocked this conversation on Jan 6, 2024

2 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/buildRelates to Dockerfiles or docker build commandkind/enhancementImproves the usability of docskind/help-wantedRelates to issues/PRs the project wants help onlifecycle/frozen

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Dockerfile best practices: clarify behavior of pipefail in RUN steps · Issue #11427 · docker/docs