The dotnet publish command published into the projects bin/netcoreapp2.2/Debug/publish folder. Where netcoreapp2.2 presumably changes with the dotnet version and Debug changes with whatever configuration the -c parameter specifies.
For CI/CD purposes this is clearly undesirable. Alternatively one can pass -o to pass an explicit output path, but again, in a CI/CI environment this path should be inside the project folder structure, e.g. something like:
dotnet publish -o publish
But, because the publish command globs up all files, it picks up previous publish attempts and recursively stores them. This can be mitigated by either cleaning the publish folder explicitly, and/or adding a to the csproj for the project but now there is a dependency between the build script and the csproj: if the publish path is changed in the build scripts for any reason without a corresponding csproj update things break.
So, the least fragile option seems to be to use the default output path as thats automatically excluded from globbing, but how to remove the version & configuration sensitivity? Is there a particularly safe way to get dotnet to tell my CI/CD environment what its output path for build / publish is?
IMP: I do not have enough so reputation to add comment
refer : dotnet publish
you could use relative path with -o option and you may end up avoiding folder name with run-time, platform identification explicitly.
or why do not you consider using build command with publish profile where you can specify explicit path. but generally relative path is less error prone.
Hope this may help you !
Related
in qmake I have
REPC_SOURCE = rpc/SomeRPC.rep
and it generates rep_SomeRPC_source.h in the root of the project. I would like to store it somewhere else to keep root as clean as possible.
Documentation says repc creates the rep_SimpleSwitch_source.h header in the build directory that you specify. But how to specify build directory?
The only option I see is to change OUT_PWD, but documentation says Do not attempt to overwrite the value of this variable.
The build directory is the folder where you run qmake (in your case it seems to be the project folder) causing the unwanted effect of obtaining a folder with the source code, intermediate files and binaries.
Instead use a different folder where you run qmake:
mkdir build
cd build
qmake /path/of/project-directory
make
I am using Jenkins to build and deploy a .Net Core microservice application. For each microservice, I am building a docker container. My dockerfile has the following in it:
ARG source
COPY ${source:-obj/Docker/publish} .
Prior to upgrading from .Net Core 2.2 to 3.1, this worked. After the upgrade, when I try to deploy, I am getting the following error:
COPY failed: stat /var/lib/docker/tmp/docker-builder609391151/obj/Docker/publish: no such file or directory
script returned exit code 1
From what I've read, it looks like .Net Core 2.2 compiled into the /obj/Docker/publish directory, but .Net Core 3.1 compiles into the /bin/Release/netcoreapp3.1 directory, however the source is still pointing to /obj/Docker/publish. I'm trying to figure out where the source arguement is defined, and how I should change this.
Update:
I decided to leave the source out entirely and hard-code the build path. I changed the copy line to
COPY /var/lib/jenkins/jobs/fusion-core/branches/master/workspace/src/CustomerAPI/obj/Release/netcoreapp3.1 .
I'm still getting an error when I try to build the docker container that says
COPY failed: stat /var/lib/docker/tmp/docker-builder356954794/var/lib/jenkins/jobs/fusion-core/branches/master/workspace/src/CustomerAPI/obj/Release/netcoreapp3.1: no such file or directory
script returned exit code 1
I'm not sure where the "/var/lib/docker/tmp/docker-builder356954794" is coming from, or why it is appending it to the front of my path, but it doesn't exist.
Still not sure how to get around this.
Some debugging suggestions in no certain order.
Default Value
${source:-obj/Docker/publish} is bash syntax that evaluates to the value of the variable source if it was defined, or obj/Docker/publish if it was not.
I'm trying to figure out where the source argument is defined, and how I should change this.
If you can't find anything that defines it to another value, it just means that the default value obj/Docker/publish was being used.
Publish directory
3.1 still uses the publish directory, but it will be at bin/Release/netcoreapp3.1/publish. Use a RUN find -type d -iname publish to find the publish directories in your container.
Dont use the full path, it will change every build. See the tmp/docker-builder356954794 in the path?
The COPY command uses relative files, based on the path in your machine (outside the docker container). So use a path that's relative to where the context directory (or Dockerfile) is. If the dockerfile is at /var/lib/jenkins/jobs/fusion-core/branches/master/workspace/src/CustomerAPI/Dockerfile and the publish directory on your machine is at /var/lib/jenkins/jobs/fusion-core/branches/master/workspace/src/CustomerAPI/bin/Release/netcoreapp3.1/publish, then use a COPY command like this:
COPY bin/Release/netcoreapp3.1/publish .
Funny paths
I'm not sure where the "/var/lib/docker/tmp/docker-builder356954794" is coming from
Containers need to share files from one directory (in your host) to another (in your container). Depending on the container technology, it uses one or more file systems or file directories.
One of those is /var/lib/docker/tmp/...
I have a script used for CI builds that adds a CONFIG variable to qmake when building via Linux. I need to do the same for Windows desktop devs from within QtCreator. This needs to be an optional (every now and then) thing, rather than the default. Hence why it is not in the .pro file permanently.
Is this possible? And if so, how do I do it?
Edit:
Example of my situation is:
base.pro
SUBDIRS = common base
DESKTOP {
SUBDIRS += app
}
CI {
SUBDIRS += app support_tools
}
Build Script:
#!/bin/bash
qmake -makefile -r -Wall CONFIG+=CI
make
So what I'd like to be able to do is to (occasionally) do the CI style build from within QtCreator. In other words, I just need to be able to pass the additional CONFIG entry to qmake.
Yes, the users could edit the pro file, but that's annoying and has the chance of getting mistakenly committed. It doesn't seem like much of an ask to be able to pass something to qmake from Creator, but I couldn't see where.
You do that in the build settings of the project. You just add CONFIG+=CI in the qmake build step (click the "Details" button to expand it). Once you're done with testing, just remove it again. Or you can create a dedicated CI build configuration that always adds CONFIG+=CI. Although in your case, you probably just want to temporarily add that, build, and then remove it again.
My build completes with no errors, but it creates a randomly named zip file (s.zip) for the release step.
After the release step, I end up with that s.zip in inetpub/wwwroot/admin-tool/ folder. I'm almost there, but I want it to unzip and dump all the contents in here. This should be automatic, shouldn't it?
My dotnet publish looks like this:
and cause this to run, which is how I get the s.zip:
C:\Program Files\dotnet\dotnet.exe publish C:\agent\_work\3\s\Angular.AdminTool.csproj -c release --output C:\agent\_work\3\a\s
If I try to edit the -o argument and make it -o $(Build.ArtifactStagingDirectory)/admin-tool I will just end up with C:\agent\_work\3\a\admin-tool\s.zip
Is getting the name of my zip to be the same as the name of my web-site (admin-tool) the key to getting the zip to automatically extract in the release step?
In case it help others, I used the simple command line tools rather than the pre-canned "dotnet core" ones:
and for the Archive files task, be sure to include a hard-coded name for the zip to be used in the build process:
And for the release, in the "Deploy IIS App" task, be sure to include the full path for the zip file:
I also ran into this issue but solved it another way.
In my case I have a single project to build and deploy.
The $(Parameters.RestoreBuildProjects) value is set to a single project
MyProjectFolder/MyProject.csproj.
In the .Net Core Publish task, this value is used in the Path to Project(s) field.
Then I tick both the boxes for
I saved and queued this pipeline.
The zip file created seems to be derived from the name of the folder
so I ended up with a zip file in the artifact staging directory with the name of the project. Then the Publish Artifact task placed this zip file into the Artifact that is named in that task.
I'm modifying an automated build, and want to tell rpmbuild to use a specific build area when invoking it.
This is similar to an existing question, but more specific.
I don't want to run any of the build commands as the root user; the aim is only to have an RPM, not to install anything into the system.
I don't want to require the user to change their dotfiles (e.g. $HOME/.rpmrc); the build should be self-contained and not affect the user's existing settings.
I don't want to hard-code the location into the foo.spec file; that file should be useable as-is if the user wants to build in a different location.
The --buildroot option is not what I need; that sets a pseudo-root filesystem for the make part of the build process, but I need to specify the “build area” for the entire RPM build process.
What I'm looking for is a hypothetical --build-area FOODIR option that can be given to the rpmbuild command, or an equivalent environment variable. It should thus affect just that single invocation of the command and cause it to use a specified user-writable location for its build area.
I've seen references to a _topdir macro that seems to be what I'm talking about, but it doesn't appear to be configurable per invocation.
It would be ideal if rpmbuild could set up its own environment in that location when it needs it, but I don't mind setting up the directories for that per build, since that can be automated as part of the build. The goal is to have that user-writable location exist only for the duration of the build run, and then clean up by deleting that entire location once the RPM file is generated.
It's not documented, but the _topdir macro determines the build area.
So you can set this per-invocation with rpmbuild --define "_topdir ${PWD}/foobar" ... to set the directory to whatever you want.
--define is the key to setting values for any macro, not just _topdir.
The --buildroot option is not what you are looking for. The name is a bit misleading as it is not changing the buildroot but instead is setting the root for the install phase of the build. RPM is basically doing a "make install" as part of the build and is then packing the results of this. The buildroot option allows you to do this install into for example /tmp/myinstallroot.
I recently had to integrate rpm package building into an automated build and had the same problem. What i did was to generate a custom .rpmmacros file with %topdir set appropriately. I then just temporarily changes HOME to the location of that custom .rpmmacros file.
"HOME=mytopdir rpmbuild ...".