In Linux I have the following RUN:
RUN dotnet restore Backend &&\
dotnet publish Backend --output /opt/src/Publish
Now I try to do it for windows container:
RUN dotnet restore IPBackend &\
dotnet publish IPBackend --output /app/publish
However I get this message:
The ampersand (&) character is not allowed. The & operator is reserved for
future use; wrap an ampersand in double quotation marks ("&") to pass it as
part of a string.
For && it also throws an error.
I fixed it by the following code:
RUN dotnet restore Backend ;\
dotnet publish Backend --output /app/publish
It works fine but I try to understand whether is it correct way or not?
If yes could anybody give a link with description?
'&&' is for command chaining it will execute command based on succesfull execution of previous command. ';' doesnt care for result of previous command and will execute even when previous command is failed.
'&' you can fork your 2 commands so a command will start executing without waiting for previous command to finish.
I would like 2 see errors you encountered with &&
Related
I'm attempting to containerize a legacy ASP.NET application that has a dependency on Web Services Enhancements (WSE) 3.0. I understand that this is a legacy technology but refactoring the application to remove it is not an option.
My Dockerfile:
FROM mcr.microsoft.com/windows/servercore/iis
RUN mkdir prereqs
WORKDIR /prereqs
COPY ["prereqs/WSE30.msi", "c:/prereqs/"]
RUN "C:\prereqs\WSE30.msi /qn /quiet /passive"
Which fails with the following:
The command 'cmd /S /C "C:\prereqs\WSE30.msi /qn /quiet /passive"' returned a non-zero code: 1603
I've tried modifying the RUN command to include logging...
RUN "C:\prereqs\WSE30.msi /qn /quiet /passive /lv c:/logs/wse30.txt"
...but this creates a condition where the docker build just seems to hang; I've let several of these attempts run for more than an hour and they do not appear to progress or complete.
I've also tried adding an "exit 0" to simply let the build continue if there is an error...
RUN "C:\prereqs\WSE30.msi /qn /quiet /passive /lv c:/logs/wse30.txt" ; exit 0
..but the result is the same. The build appears to hang and never complete.
I know that this particular MSI supports unattended/silent installation as I've done so in batch files.
#DWRoelands , I faced the same issue but I was able to install it on the windowservercore:1909 after installing the all web-serverr and all its subcomponents components.
You will have to set the source of .Net3.5 to the downloaded file of https://dotnetbinaries.blob.core.windows.net/dockerassets/microsoft-windows-netfx3-1909.zip
I have a few Docker builds on Azure DevOps for React apps which include packages from a private npm feed also hosted on Azure DevOps. Recently the builds have started failing at the npm install command.
In order to authenticate the container to install from the private feed I've always used an .npmrc file. This is saved locally as .npmrc.docker and looks like this:
#<package-scope>:registry=https://<devops-username>.pkgs.visualstudio.com/_packaging/<feed-name>/npm/registry/
//<devops-username>.pkgs.visualstudio.com/_packaging/<feed-name>/npm/registry/:username=<feed-name>
//<devops-username>.pkgs.visualstudio.com/_packaging/<feed-name>/npm/registry/:_password=${NPM_TOKEN}
//<devops-username>.pkgs.visualstudio.com/_packaging/<feed-name>/npm/registry/:email=npm requires email to be set but doesn't use the value
//<devops-username>.pkgs.visualstudio.com/_packaging/<feed-name>/npm/:username=<feed-name>
//<devops-username>.pkgs.visualstudio.com/_packaging/<feed-name>/npm/:_password=${NPM_TOKEN}
//<devops-username>.pkgs.visualstudio.com/_packaging/<feed-name>/npm/:email=npm requires email to be set but doesn't use the value
I define a scoped package source at the top and the rest is generated from Azure DevOps via its Connect to feed wizard. ${NPM_TOKEN} is my feed password which I pass into the docker build command as a build argument.
The part of my Dockerfile which uses this looks like this:
FROM node:alpine as build
ARG NPM_TOKEN
COPY ./.npmrc.docker /app/.npmrc
COPY ./package.json /app/package.json
WORKDIR /app
RUN npm install
RUN rm -f .npmrc
In my Azure DevOps build pipeline this has always worked. The Build image part of the pipeline feeds in this build arg from a variable like this - --build-arg NPM_TOKEN=$(ArtifactsNpmPat) - where ArtifactsNpmPat is a variable in my library.
Recently my builds have started failing. Initially I assumed my token had expired so I generated and stored a new one. Here's the error from the agent:
[error]The command '/bin/sh -c npm install' returned a non-zero code: 1
[error]The process '/usr/bin/docker' failed with exit code 1
Note that the same process continues to work locally. So I've no idea how to diagnose this. I did find this SO post which led me to update my Dockerfile to look like this:
FROM node:alpine as build
ARG NPM_TOKEN
COPY ./.npmrc.docker /app/.npmrc
COPY ./package.json /app/package.json
WORKDIR /app
RUN npm install -g vsts-npm-auth
RUN vsts-npm-auth -config .npmrc
RUN npm install
RUN rm -f .npmrc
However, a docker build now generates a pretty crazy error from the RUN vsts-npm-auth command.
/usr/local/bin/vsts-npm-auth: line 1: MZ�╚╝���#���: not found
/usr/local/bin/vsts-npm-auth: line 1: �ԞO���: not found
/usr/local/bin/vsts-npm-auth: line 57: ╔╚��║[�
╔0�
&� �# ╗╝═�╗��╔╚.rsrc�##.reloc
�╗�#�H╗║�?�Y
╗*═d��╚���╗(&
╗╚s'
}║╝╗╗╚═}═╝*╗{═╝*0╗4╔╗╚( ═╔╗╚(
═╔╚╚(
═╔╗╚(
═╔╗╚(
+═*0╔╗╚/(═
+═*0╝M╗╗{║╝o(
═()
�╔
,+╚═o*
�╔ ,s+
z═o,
Xo-
╝+║╚╝+╝*0╔╗╚?(═
+═*0╔╗╚#(═
+═*0A╚╚r╔po.
-╗{║╝o/
r╔p(0
+╔
═,║╚
+╗╚/(═
+*0╝�╝╗╚╝║(═
═�╔ ,&═╝╝,r║p╝�S╔╚(1
s2
z╚║+Z╚═o3
╚╚o,
═X(4
o5
╝-╚+║rgp║-╗(6
%-═&rgp+║rgp╝-rgp+(7
║+║*0╗║║- ╚╝o8
+╚╝o9
+═*0╚L╗(&
╗╚}
╝╗║}╝╗═}╝╗╗(═}╝*╝═
╗{╝o:
╗(╗{
╝s;
╗(═o
╝+#╝o
║╗ ║(═══�╚,╗
╝o
╝╝o
0�s<╔╗30c
╗{╝ripo=
�╚,E(>
r�p�╔%rip�%�(?
�S╔%;�o#
═ sA
oB
═╚╗{╝sC
oB
═sD
╝+╝*0║╗{╝-rp╔p+║r�╔p
╝═╗{╝oE
+*0╗# ╗{
╝%-
&╗{╝(═: not found
/usr/local/bin/vsts-npm-auth: line 58: syntax error: unexpected word (expecting ")")
So I'm stuck. Has something changed in DevOps around authenticating with its private feeds? Not that I'm aware of, but like I say these builds just stopped working some time in October without me changing anything. Advice appreciated.
You are trying to run vsts-npm-auth which is not compatible with Linux platform, which in azure docs in documentation is explained that you only need .npmrc file with credentials
As answered by dawid debinski, vsts-npm-auth doesn't run on Linux platform as written here.
Check this documentation out in which you have to authenticate your pipeline with npm authenticate, or use the YAML version.
I have a CI project in jenkins just to run some tests and send a report via email.
Running it from a docker console(or ubuntu) there is no probelm , it runs the test and send the report via email.
But when i try to run the same command on jenkins it never runs the last command in order to send the report via email.
Here is the command
python3 -m venv . && . bin/activate && pip3 install -r requirements.txt && pytest testcases/HotelesCI/Desktop/HotelPlaya --html=/home/jenkins/hoteles_playa_desktop.html --reruns 2 --self-contained-html --tb=line -k 'test_errors' ; python3 testcases/HotelesCI/Desktop/HotelPlaya/hotels_report.py
Again if i copy and paste into a console there is no probelm
I even try to run the last command in another build shell step , but nothing happens
Am i missing something? there is no output in jenkins for the las command
Solved even i don fully understand why , changing the last concatenation quote from " ; " to " || ", it solves the problem.
As i understand , the first option should run the last command always even on build failure , and my change is telling the system that run it only on failure
Following all .NET Core guides basically boils down to a dotnet publish and copying the output of that to /app, then running dotnet myapp.dll.
I have about 40+ (and growing) products running in this setup, and so modifying all dockerfiles with myapp.dll gets quite laborious.
I was wondering if there is some way to find out what the entry dll is during publish? (e.g. with --self-contained the cli generates an arch specific entry file, so you can use that name, but it seems like an unnecessary step given that publish takes longer)
You can create a bash script which will extract project name, and next create a valid path with replacing it in script file.
If you are in solution folder just run: (bash)
PROJECT_NAME=`find ./ -name "*.sln" | head -n 1 | cut -d '/' -f 2 | sed 's/.sln//'`
If you have solution file myapp.sln , this command will return value myapp
Then you pass this value to script:
./runScript.sh "$PROJECT_NAME"
And inside this script:
dotnet "/app/$1.dll"
For dockerfiles you have replace all occurences of eg. {{PROJECT_NAME}} in file to value of variable. Now i don't remember command, but sed is useful for that.
I'm trying to configure running simple .NET Core Web API application inside Docker container. My dockerfile contains following ENTRYPOINT line:
ENTRYPOINT ["dotnet", "Project.name.dll"]
Dockerfile builds image proper. When I run it however I have following exception:
No executable found matching command "dotnet-Project.name.dll"
I don't understand why parameter is transformed in that way (added hyphen). I use microsoft/dotnet:2.0.0-sdk-stretch container. Official documentation recommends following ENTRYPOINT config
ENTRYPOINT ["dotnet", "dotnetapp.dll"]
Which is the same as I use...
It's a bizarre error message, but it really is saying that the dll can not be found. You can see other examples of this "issue" here: https://github.com/dotnet/core-setup/issues/1126#issuecomment-327441394
When you run dotnet foo.dll, the dotnet application tries to find foo.dll and execute it. If the dll is not found, dotnet thinks that maybe you are trying to run a dotnet command (along the lines of dotnet foo, similar to dotnet build). This makes dotnet look for an executible named dotnet-foo.dll and try and execute that. Since that file also doesn't exist, dotnet finally errors out that dotnet-foo.dll can not be found.
In your case, it looks like dotnet couldn't find Project.name.dll. Does the dll really exist? Does it exist in the current directory? Perhaps you need to provide the full path to it?
Oh, and if you are running this on Azure, there are some known gotchas, such as putting your dlls under /home/ will just not work.