Why do we build and publish as two steps when publish also builds?
Sorry if this is a stupid question, but why does the dockerfile include steps to build and publish when the publish also builds?
The following Dockerfile is created in my web application:
FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 80
FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
RUN dotnet restore "WebApplication1/WebApplication1.csproj"
COPY . .
WORKDIR "/src/WebApplication1"
RUN dotnet build "WebApplication1.csproj" -c Release -o /app
FROM build AS publish
RUN dotnet publish "WebApplication1.csproj" -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]
c# .net asp.net-core visual-studio-2017 dockerfile
add a comment |
Sorry if this is a stupid question, but why does the dockerfile include steps to build and publish when the publish also builds?
The following Dockerfile is created in my web application:
FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 80
FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
RUN dotnet restore "WebApplication1/WebApplication1.csproj"
COPY . .
WORKDIR "/src/WebApplication1"
RUN dotnet build "WebApplication1.csproj" -c Release -o /app
FROM build AS publish
RUN dotnet publish "WebApplication1.csproj" -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]
c# .net asp.net-core visual-studio-2017 dockerfile
3
Early failure detection?
– cricket_007
Nov 16 '18 at 6:33
Maybe, but the build is early enough in the publish that it may not make a difference.
– Martin Lottering
Nov 16 '18 at 6:37
You're welcome to edit the Dockerfile. You don't have to use what it provides
– cricket_007
Nov 16 '18 at 6:41
Depends on what "publish" is doing exactly. If there are steps taken on the deploy target before the "build" step, it may mess up your deployment if the build fails only then. So better check up front if it will build. I'd say only a "security" measure that may not be necessary, but probably "good practice".
– Fildor
Nov 16 '18 at 8:00
add a comment |
Sorry if this is a stupid question, but why does the dockerfile include steps to build and publish when the publish also builds?
The following Dockerfile is created in my web application:
FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 80
FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
RUN dotnet restore "WebApplication1/WebApplication1.csproj"
COPY . .
WORKDIR "/src/WebApplication1"
RUN dotnet build "WebApplication1.csproj" -c Release -o /app
FROM build AS publish
RUN dotnet publish "WebApplication1.csproj" -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]
c# .net asp.net-core visual-studio-2017 dockerfile
Sorry if this is a stupid question, but why does the dockerfile include steps to build and publish when the publish also builds?
The following Dockerfile is created in my web application:
FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 80
FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
RUN dotnet restore "WebApplication1/WebApplication1.csproj"
COPY . .
WORKDIR "/src/WebApplication1"
RUN dotnet build "WebApplication1.csproj" -c Release -o /app
FROM build AS publish
RUN dotnet publish "WebApplication1.csproj" -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]
c# .net asp.net-core visual-studio-2017 dockerfile
c# .net asp.net-core visual-studio-2017 dockerfile
edited Nov 16 '18 at 6:34
cricket_007
83.5k1146116
83.5k1146116
asked Nov 16 '18 at 6:25
Martin LotteringMartin Lottering
8571322
8571322
3
Early failure detection?
– cricket_007
Nov 16 '18 at 6:33
Maybe, but the build is early enough in the publish that it may not make a difference.
– Martin Lottering
Nov 16 '18 at 6:37
You're welcome to edit the Dockerfile. You don't have to use what it provides
– cricket_007
Nov 16 '18 at 6:41
Depends on what "publish" is doing exactly. If there are steps taken on the deploy target before the "build" step, it may mess up your deployment if the build fails only then. So better check up front if it will build. I'd say only a "security" measure that may not be necessary, but probably "good practice".
– Fildor
Nov 16 '18 at 8:00
add a comment |
3
Early failure detection?
– cricket_007
Nov 16 '18 at 6:33
Maybe, but the build is early enough in the publish that it may not make a difference.
– Martin Lottering
Nov 16 '18 at 6:37
You're welcome to edit the Dockerfile. You don't have to use what it provides
– cricket_007
Nov 16 '18 at 6:41
Depends on what "publish" is doing exactly. If there are steps taken on the deploy target before the "build" step, it may mess up your deployment if the build fails only then. So better check up front if it will build. I'd say only a "security" measure that may not be necessary, but probably "good practice".
– Fildor
Nov 16 '18 at 8:00
3
3
Early failure detection?
– cricket_007
Nov 16 '18 at 6:33
Early failure detection?
– cricket_007
Nov 16 '18 at 6:33
Maybe, but the build is early enough in the publish that it may not make a difference.
– Martin Lottering
Nov 16 '18 at 6:37
Maybe, but the build is early enough in the publish that it may not make a difference.
– Martin Lottering
Nov 16 '18 at 6:37
You're welcome to edit the Dockerfile. You don't have to use what it provides
– cricket_007
Nov 16 '18 at 6:41
You're welcome to edit the Dockerfile. You don't have to use what it provides
– cricket_007
Nov 16 '18 at 6:41
Depends on what "publish" is doing exactly. If there are steps taken on the deploy target before the "build" step, it may mess up your deployment if the build fails only then. So better check up front if it will build. I'd say only a "security" measure that may not be necessary, but probably "good practice".
– Fildor
Nov 16 '18 at 8:00
Depends on what "publish" is doing exactly. If there are steps taken on the deploy target before the "build" step, it may mess up your deployment if the build fails only then. So better check up front if it will build. I'd say only a "security" measure that may not be necessary, but probably "good practice".
– Fildor
Nov 16 '18 at 8:00
add a comment |
2 Answers
2
active
oldest
votes
Build is used when we add some reference/service/entities in our code and when partial completed code need to debug . in debug mode every time we need to compile with build when the code is 100% completed it no need to built . directly build by publish.
Are you saying that the "dotnet build" will always build, whereas the "dotnet publish" may skip the build, even if a reference was added? I find that hard to believe, but it might explain the explicit build step.
– Martin Lottering
Nov 16 '18 at 8:02
add a comment |
According to the book .NET Microservices: Architecture for Containerized .NET Applications (Microsoft EBook), the first build instruction is redundant because the publish instruction also builds, and it is right after the first build instruction. Page 94 (86), line 10.
Here is a short excerpt from the book:
1 FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
2 WORKDIR /app
3 EXPOSE 80
4
5 FROM microsoft/dotnet:2.1-sdk AS build
6 WORKDIR /src
7 COPY src/Services/Catalog/Catalog.API/Catalog.API.csproj …
8 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.AspNetCore.HealthChecks …
9 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions.HealthChecks …
10 COPY src/BuildingBlocks/EventBus/IntegrationEventLogEF/ …
11 COPY src/BuildingBlocks/EventBus/EventBus/EventBus.csproj …
12 COPY src/BuildingBlocks/EventBus/EventBusRabbitMQ/EventBusRabbitMQ.csproj …
13 COPY src/BuildingBlocks/EventBus/EventBusServiceBus/EventBusServiceBus.csproj …
14 COPY src/BuildingBlocks/WebHostCustomization/WebHost.Customization …
15 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions …
16 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions …
17 RUN dotnet restore src/Services/Catalog/Catalog.API/Catalog.API.csproj
18 COPY . .
19 WORKDIR /src/src/Services/Catalog/Catalog.API
20 RUN dotnet build Catalog.API.csproj -c Release -0 /app
21
22 FROM build AS publish
23 RUN dotnet publish Catalog.API.csproj -c Release -0 /app
24
25 FROM base AS final
26 WORKDIR /app
27 COPY --from=publish /app
28 ENTRYPOINT ["dotnet", "Catalog.API.dll"]
For the final optimization, it just happens that line 20 is redundant,
as line 23 also builds the application and comes, in essence, right
after line 20, so there goes another time-consuming command.
While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review
– Roy Scheffers
Nov 30 '18 at 12:28
1
@RoyScheffers, I fixed it. Thanks for pointing that out.
– Martin Lottering
Dec 6 '18 at 9:38
1
I've added the code from the book related to the quote as well.
– Roy Scheffers
Dec 8 '18 at 13:08
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53332539%2fwhy-do-we-build-and-publish-as-two-steps-when-publish-also-builds%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Build is used when we add some reference/service/entities in our code and when partial completed code need to debug . in debug mode every time we need to compile with build when the code is 100% completed it no need to built . directly build by publish.
Are you saying that the "dotnet build" will always build, whereas the "dotnet publish" may skip the build, even if a reference was added? I find that hard to believe, but it might explain the explicit build step.
– Martin Lottering
Nov 16 '18 at 8:02
add a comment |
Build is used when we add some reference/service/entities in our code and when partial completed code need to debug . in debug mode every time we need to compile with build when the code is 100% completed it no need to built . directly build by publish.
Are you saying that the "dotnet build" will always build, whereas the "dotnet publish" may skip the build, even if a reference was added? I find that hard to believe, but it might explain the explicit build step.
– Martin Lottering
Nov 16 '18 at 8:02
add a comment |
Build is used when we add some reference/service/entities in our code and when partial completed code need to debug . in debug mode every time we need to compile with build when the code is 100% completed it no need to built . directly build by publish.
Build is used when we add some reference/service/entities in our code and when partial completed code need to debug . in debug mode every time we need to compile with build when the code is 100% completed it no need to built . directly build by publish.
answered Nov 16 '18 at 6:54
Vignesh DVignesh D
85
85
Are you saying that the "dotnet build" will always build, whereas the "dotnet publish" may skip the build, even if a reference was added? I find that hard to believe, but it might explain the explicit build step.
– Martin Lottering
Nov 16 '18 at 8:02
add a comment |
Are you saying that the "dotnet build" will always build, whereas the "dotnet publish" may skip the build, even if a reference was added? I find that hard to believe, but it might explain the explicit build step.
– Martin Lottering
Nov 16 '18 at 8:02
Are you saying that the "dotnet build" will always build, whereas the "dotnet publish" may skip the build, even if a reference was added? I find that hard to believe, but it might explain the explicit build step.
– Martin Lottering
Nov 16 '18 at 8:02
Are you saying that the "dotnet build" will always build, whereas the "dotnet publish" may skip the build, even if a reference was added? I find that hard to believe, but it might explain the explicit build step.
– Martin Lottering
Nov 16 '18 at 8:02
add a comment |
According to the book .NET Microservices: Architecture for Containerized .NET Applications (Microsoft EBook), the first build instruction is redundant because the publish instruction also builds, and it is right after the first build instruction. Page 94 (86), line 10.
Here is a short excerpt from the book:
1 FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
2 WORKDIR /app
3 EXPOSE 80
4
5 FROM microsoft/dotnet:2.1-sdk AS build
6 WORKDIR /src
7 COPY src/Services/Catalog/Catalog.API/Catalog.API.csproj …
8 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.AspNetCore.HealthChecks …
9 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions.HealthChecks …
10 COPY src/BuildingBlocks/EventBus/IntegrationEventLogEF/ …
11 COPY src/BuildingBlocks/EventBus/EventBus/EventBus.csproj …
12 COPY src/BuildingBlocks/EventBus/EventBusRabbitMQ/EventBusRabbitMQ.csproj …
13 COPY src/BuildingBlocks/EventBus/EventBusServiceBus/EventBusServiceBus.csproj …
14 COPY src/BuildingBlocks/WebHostCustomization/WebHost.Customization …
15 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions …
16 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions …
17 RUN dotnet restore src/Services/Catalog/Catalog.API/Catalog.API.csproj
18 COPY . .
19 WORKDIR /src/src/Services/Catalog/Catalog.API
20 RUN dotnet build Catalog.API.csproj -c Release -0 /app
21
22 FROM build AS publish
23 RUN dotnet publish Catalog.API.csproj -c Release -0 /app
24
25 FROM base AS final
26 WORKDIR /app
27 COPY --from=publish /app
28 ENTRYPOINT ["dotnet", "Catalog.API.dll"]
For the final optimization, it just happens that line 20 is redundant,
as line 23 also builds the application and comes, in essence, right
after line 20, so there goes another time-consuming command.
While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review
– Roy Scheffers
Nov 30 '18 at 12:28
1
@RoyScheffers, I fixed it. Thanks for pointing that out.
– Martin Lottering
Dec 6 '18 at 9:38
1
I've added the code from the book related to the quote as well.
– Roy Scheffers
Dec 8 '18 at 13:08
add a comment |
According to the book .NET Microservices: Architecture for Containerized .NET Applications (Microsoft EBook), the first build instruction is redundant because the publish instruction also builds, and it is right after the first build instruction. Page 94 (86), line 10.
Here is a short excerpt from the book:
1 FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
2 WORKDIR /app
3 EXPOSE 80
4
5 FROM microsoft/dotnet:2.1-sdk AS build
6 WORKDIR /src
7 COPY src/Services/Catalog/Catalog.API/Catalog.API.csproj …
8 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.AspNetCore.HealthChecks …
9 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions.HealthChecks …
10 COPY src/BuildingBlocks/EventBus/IntegrationEventLogEF/ …
11 COPY src/BuildingBlocks/EventBus/EventBus/EventBus.csproj …
12 COPY src/BuildingBlocks/EventBus/EventBusRabbitMQ/EventBusRabbitMQ.csproj …
13 COPY src/BuildingBlocks/EventBus/EventBusServiceBus/EventBusServiceBus.csproj …
14 COPY src/BuildingBlocks/WebHostCustomization/WebHost.Customization …
15 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions …
16 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions …
17 RUN dotnet restore src/Services/Catalog/Catalog.API/Catalog.API.csproj
18 COPY . .
19 WORKDIR /src/src/Services/Catalog/Catalog.API
20 RUN dotnet build Catalog.API.csproj -c Release -0 /app
21
22 FROM build AS publish
23 RUN dotnet publish Catalog.API.csproj -c Release -0 /app
24
25 FROM base AS final
26 WORKDIR /app
27 COPY --from=publish /app
28 ENTRYPOINT ["dotnet", "Catalog.API.dll"]
For the final optimization, it just happens that line 20 is redundant,
as line 23 also builds the application and comes, in essence, right
after line 20, so there goes another time-consuming command.
While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review
– Roy Scheffers
Nov 30 '18 at 12:28
1
@RoyScheffers, I fixed it. Thanks for pointing that out.
– Martin Lottering
Dec 6 '18 at 9:38
1
I've added the code from the book related to the quote as well.
– Roy Scheffers
Dec 8 '18 at 13:08
add a comment |
According to the book .NET Microservices: Architecture for Containerized .NET Applications (Microsoft EBook), the first build instruction is redundant because the publish instruction also builds, and it is right after the first build instruction. Page 94 (86), line 10.
Here is a short excerpt from the book:
1 FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
2 WORKDIR /app
3 EXPOSE 80
4
5 FROM microsoft/dotnet:2.1-sdk AS build
6 WORKDIR /src
7 COPY src/Services/Catalog/Catalog.API/Catalog.API.csproj …
8 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.AspNetCore.HealthChecks …
9 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions.HealthChecks …
10 COPY src/BuildingBlocks/EventBus/IntegrationEventLogEF/ …
11 COPY src/BuildingBlocks/EventBus/EventBus/EventBus.csproj …
12 COPY src/BuildingBlocks/EventBus/EventBusRabbitMQ/EventBusRabbitMQ.csproj …
13 COPY src/BuildingBlocks/EventBus/EventBusServiceBus/EventBusServiceBus.csproj …
14 COPY src/BuildingBlocks/WebHostCustomization/WebHost.Customization …
15 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions …
16 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions …
17 RUN dotnet restore src/Services/Catalog/Catalog.API/Catalog.API.csproj
18 COPY . .
19 WORKDIR /src/src/Services/Catalog/Catalog.API
20 RUN dotnet build Catalog.API.csproj -c Release -0 /app
21
22 FROM build AS publish
23 RUN dotnet publish Catalog.API.csproj -c Release -0 /app
24
25 FROM base AS final
26 WORKDIR /app
27 COPY --from=publish /app
28 ENTRYPOINT ["dotnet", "Catalog.API.dll"]
For the final optimization, it just happens that line 20 is redundant,
as line 23 also builds the application and comes, in essence, right
after line 20, so there goes another time-consuming command.
According to the book .NET Microservices: Architecture for Containerized .NET Applications (Microsoft EBook), the first build instruction is redundant because the publish instruction also builds, and it is right after the first build instruction. Page 94 (86), line 10.
Here is a short excerpt from the book:
1 FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
2 WORKDIR /app
3 EXPOSE 80
4
5 FROM microsoft/dotnet:2.1-sdk AS build
6 WORKDIR /src
7 COPY src/Services/Catalog/Catalog.API/Catalog.API.csproj …
8 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.AspNetCore.HealthChecks …
9 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions.HealthChecks …
10 COPY src/BuildingBlocks/EventBus/IntegrationEventLogEF/ …
11 COPY src/BuildingBlocks/EventBus/EventBus/EventBus.csproj …
12 COPY src/BuildingBlocks/EventBus/EventBusRabbitMQ/EventBusRabbitMQ.csproj …
13 COPY src/BuildingBlocks/EventBus/EventBusServiceBus/EventBusServiceBus.csproj …
14 COPY src/BuildingBlocks/WebHostCustomization/WebHost.Customization …
15 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions …
16 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.Extensions …
17 RUN dotnet restore src/Services/Catalog/Catalog.API/Catalog.API.csproj
18 COPY . .
19 WORKDIR /src/src/Services/Catalog/Catalog.API
20 RUN dotnet build Catalog.API.csproj -c Release -0 /app
21
22 FROM build AS publish
23 RUN dotnet publish Catalog.API.csproj -c Release -0 /app
24
25 FROM base AS final
26 WORKDIR /app
27 COPY --from=publish /app
28 ENTRYPOINT ["dotnet", "Catalog.API.dll"]
For the final optimization, it just happens that line 20 is redundant,
as line 23 also builds the application and comes, in essence, right
after line 20, so there goes another time-consuming command.
edited Dec 8 '18 at 13:06
Roy Scheffers
2,258102027
2,258102027
answered Nov 19 '18 at 7:22
Martin LotteringMartin Lottering
8571322
8571322
While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review
– Roy Scheffers
Nov 30 '18 at 12:28
1
@RoyScheffers, I fixed it. Thanks for pointing that out.
– Martin Lottering
Dec 6 '18 at 9:38
1
I've added the code from the book related to the quote as well.
– Roy Scheffers
Dec 8 '18 at 13:08
add a comment |
While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review
– Roy Scheffers
Nov 30 '18 at 12:28
1
@RoyScheffers, I fixed it. Thanks for pointing that out.
– Martin Lottering
Dec 6 '18 at 9:38
1
I've added the code from the book related to the quote as well.
– Roy Scheffers
Dec 8 '18 at 13:08
While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review
– Roy Scheffers
Nov 30 '18 at 12:28
While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review
– Roy Scheffers
Nov 30 '18 at 12:28
1
1
@RoyScheffers, I fixed it. Thanks for pointing that out.
– Martin Lottering
Dec 6 '18 at 9:38
@RoyScheffers, I fixed it. Thanks for pointing that out.
– Martin Lottering
Dec 6 '18 at 9:38
1
1
I've added the code from the book related to the quote as well.
– Roy Scheffers
Dec 8 '18 at 13:08
I've added the code from the book related to the quote as well.
– Roy Scheffers
Dec 8 '18 at 13:08
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53332539%2fwhy-do-we-build-and-publish-as-two-steps-when-publish-also-builds%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
Early failure detection?
– cricket_007
Nov 16 '18 at 6:33
Maybe, but the build is early enough in the publish that it may not make a difference.
– Martin Lottering
Nov 16 '18 at 6:37
You're welcome to edit the Dockerfile. You don't have to use what it provides
– cricket_007
Nov 16 '18 at 6:41
Depends on what "publish" is doing exactly. If there are steps taken on the deploy target before the "build" step, it may mess up your deployment if the build fails only then. So better check up front if it will build. I'd say only a "security" measure that may not be necessary, but probably "good practice".
– Fildor
Nov 16 '18 at 8:00