I am using Mongooseim 3.2.0 and after compiling it from the source code, I can see the mongooseim.cfg at:
1. /MongooseIM/_build/prod/rel/mongooseim/etc/mongooseim.cfg
I can also see that in the docs here that there is another mongooseim.cfg at root level -
2. /MoongoosIM/rel/files/mongooseim.cfg
What is the difference between the two? My guess is path 1 file is copied to the path[2] after compiling the project.
Path 1 (/MongooseIM/_build/prod/rel/mongooseim/etc/mongooseim.cfg) is the actual config file of MongooseIM once it's built. You can tell that by MongooseIM/_build in the path - the _build directory doesn't exist in a fresh clone of the repository. To give you more context, /MongooseIM/_build/prod/rel/mongooseim is a self-contained Erlang release of MongooseIM. Change this file if you want to modify the config of this particular MongooseIM build - the changes will be lost after you rebuild.
Path 2 (/MoongoosIM/rel/files/mongooseim.cfg) is cloned as part of the repository - it's a config template. The specific values are defined in rel/*vars.config files and are substituted for the variables in the template file at build time depending on the Rebar3 profile in use (see rebar.config for profiles). Change this file if you want your changes to remain after consecutive rebuilds of the project.
To cut the long story short, when you run make rel the files /MoongoosIM/rel/files/mongooseim.cfg and /MoongoosIM/rel/vars.config are used to create /MongooseIM/_build/prod/rel/mongooseim/etc/mongooseim.cfg.
Related
Question
When building Singularity images using definition files, is there a way to specify the path to a file on the host system relative to the definition file (i.e. independent of where the build command is called)?
Example to Illustrate the Problem
I have the following files in the same directory (e.g. a git repository):
foobar.def
some_file.txt
foobar.def looks as follows:
Bootstrap: library
From: ubuntu:20.04
Stage: build
%files
# Add some_file.txt at the root of the image
some_file.txt /some_file.txt
This works fine when I build with the following command in the directory which contains the files:
singularity build --fakeroot foobar.sif foobar.def
However, it fails if I call the build command from anywhere else (e.g. from a dedicated "build" directory) because it searches some_file.txt relative to the current working directory of the build command, not relative to the definition file.
Is there a way to implement the definition file such that the build works independently of where the command is called? I know that I could use absolute paths but this is not a viable solution in my case.
To make it even more complicated: My actual definition file is bootstrapping from another local image, which is located in the build directory. So ideally I would need a solution where some files are found relative the working directory while others are found relative to the location of the definition file.
Short answer: Not really
Longer answer: Not really, but there's a reason why and it shouldn't really matter for most use cases. While Docker went the route of letting you specify what your directory context is, Singularity decided to base all of its commands off the current directory where it is being executed. This also follows with $PWD being auto-mounted into the container, so it makes sense for it to be consistent.
That said, is there a reason you can't run singularity build --fakeroot $build_dir/foobar.sif foobar.def from the repo directory? There isn't any other output written besides the final image and it makes more sense for the directory with the data being used to be the context to work from.
I have created build definition which runs successfully. Now I want to create a release definition on the successful build, for which it is asking for artifacts.
When I tried browsing "Drop" folder, I found it empty.
Below are the images from Copy Files step and Publish build artifacts step.
I also tried instructions from The item MY_ARTIFACT_NAME in container XXX could not be found
But no luck. Please help.
I believe that you should use $(build.sourcesdirectory) (or a path relative to) as the source folder if you want to copy files which are not checked in.
Also, from the documentation of the Copy Files step
The pattern is used to match only file paths, not folder paths. So you should specify patterns such as **\bin\** instead of of **\bin.
Try changing the contents pattern to **\bin\** and see if that helps.
I have one simple plan with one simple job.
Tasks:
Source code checkout
MSBuild
Run tests
Generate test report
In four steps, my utility generates a test report with screenshots. The report contain absolute links to images. (for example: onclick="window.open('./Screenshots/66ef3a03-8b82-4b40-b49d-b0155e273738.png');return false;").
If I open the report on my local machine, the report works fine, but on Bamboo I receive the error "Page Not Found", because Bamboo has not collected "Screenshots" folder.
How can I set up the Artifact Definition to collect folder with files?
P.S. I tried to set the \*.* copy pattern, but Bamboo collected only files (without folders and subfolders)
You just have to give the folder Location, like "build/", for instance, and then, in the Copy Pattern you can put **/*.* That should copy all the files you want.
Please note that:
The location is relative to the build directory. Do not use the absolute path to refer to the location.
Asterisks are not supported for Location. For this field, provide the folder name where the file would be located.
Plus, you can define as many Artifact Definitions as you want.
The best way of doing this is to zip all you artifact together. I created a bash script to do this
cd "toArtifactFolder"
zip -r Artifact .
Then in bamboo project settings you have to edit the Artifact and changed the location to where ever the artifact zip file is
Then in the Copy Pattern just enter the zip file eg Artifact.zip
Bamboo uses the "Ant file copy pattern".
Matching recursively against all files: **/*
This does include almost everything
Unfortunately this does not include dot-files, at least in my test on a linux build agent. I could not find a workaround apart from a second artifact (pattern **/.*) or the creation of an archive.
Matching against all files in any subfolder: */*
This does not include foo/bar/test.xyz
This does include both foo/test.xyz and bar/test.xyz
You can do more advanced matching; e.g. you can use build/**/*.jar to copy all jars from a build directory.
For further info see the docs
I made a sample project called "Stack", but realized that i needed some more data structures, so i renamed everything - the project, made 2 new folders & their matching groups in XCode, modified the Target Build path to look for "Main/DataStructures-Prefix.pch" instead. But there's one file i don't understand -> earlier, i had gotten a "Stack.1" in my folder, so i just renamed it to "Main.1" and it doesn't seem to be affecting the build process, but i'm pretty skeptical. What does this "Main.1" do? is it the linked intermediate file like in C/C++?
here's a picture:
"Main.1" is a template for creating a "man page" (i.e. an on-line manual page) for your program. You can verify that by calling
man ./Main.1
on the command line in the directory where "Main.1" is located.
If you run
xcodebuild install
on the command line then the manual page is copied to the
$DSTROOT/usr/share/man/man1/
directory, where DSTROOT is the "Installation Build Products Location". The file is not used otherwise in the build process.
If you don't need a man page, you can just remove the file from the Xcode project.
I am working on an embedded system that uses buildroot as a tool for building the kernel and the root filesystem. I want to apply some patches to this kernel source tree, Can somebody tell me how buildroot apply patches?
To expand on #pradeepchhentri's answer. Quilt will look for a file located in the same folder as the *.mk file. To construct the appropriate file:
diff your source package from the original into a file called
packagename-number-description.patch
where
packagename - has to be identical to the package name
number - is the order in which the patches should be applied if you have more than one patch to apply (otherwise it will be applied alphabetically)
description - can be any free text
Place this file into the package at the same level as the [packagename].mk file and the package/Config.in file.
Don't forget to blow away your build files or do a [package]-rebuild if you do this. You should see a "Patching..." message if this is done correctly.
some details about patch files in the buildroot project:
you have to
diff -u "old_file" "new_file" > file.patch
while standing exactly above extracted location of your package tar.gz defined in
PACKAGE_NAME_SOURCE
it means, your path to the file must include extracted package folder name.
in case you wonder if the "old_file" path would be different from the original one - don't worry, the important one is the "new_file" path and name - it should match your package extracted one.
naming convention for the patches already used/defined in buildroot (all parts are separated with '-' sign):
4 digits patch priority (starting from 0001)
target filename
reason for patching
.patch extention
example:
0001-configure.ac-convert-AC_TRY_COMPILE-AC_COMPILE_IFELS.patch
deposit patch file inside buildroot/package/"your package name"/ folder.
there is no need for configuration files to modify, all patches will be tried for application automatically.
in case of the failure, the reject-patch file (named similar to the file you are trying to patch but with .rej extention) will be deposited inside package extracted folder.
Use *_OVERRIDE_SRCDIR and track everything in submodules
Instead of using patches, I highly recommend that you to this instead:
myproject/
.git/
submodules/buildroot/
submodules/source_of_my_package/
and just track the source of your in a submodule that points to your fork of the project with your patches on top.
This will make everything much saner and easy to keep track of.
More info at: How to modify the source of Buildroot packages for package development?
BR2_GLOBAL_PATCH_DIR out-of-tree patches
Directory structure:
.git/
buildroot/ Buildroot submodule as mentioned at: https://stackoverflow.com/a/23635403/895245
global_patch_dir/packagename/0001-my-test.patch
Add to config:
BR2_GLOBAL_PATCH_DIR=../global_patch_dir
Then build with:
cd buildroot
make
The patch should be applied to output/build/packagename-1.0.0/ before build.
After studying the buildroot architecture, I came to know that buildroot uses quilt tool for applying the patches. quilt keeps track of all the patches in the a file named "series" which is present in the "patches" directory. You have to keep your patches in this directory. And add your entry of patches in the series file in the order in which you want the patches to be applied keeping the patch to be applied first at the top.
This way when you will run the buildroot makefile, it will automatically apply the patches listed in the series file.