Is it possible to have more than one source checkout step in BuildBot? I can't find any explicit documentation of this, but it appears that doing a source checkout in BuildBot also changes the current working directory to the checkout directory, which means it's unclear where one would "go" to checkout from another repository and then run a script that uses both.
Consider the example at http://buildbot.net/buildbot/docs/0.8.1/BuildFactory.html:
From the steps, it appears that a CVS checkout is performed and then make build is run. That is two steps in BuildBot, which is convenient.
However, if you were do to the equivalent from the command line, it would be three steps:
cvs co $CVSROOT
cd directory_that_was_created
make build
Where does the cd directory_that_was_created step happen in BuildBot?
But more importantly, what if I want to have two source.CVS (well, really source.Git) steps? What directory am I in after I run the second step? Does the second repo end up in a subdirectory of the first repo?
With Git, it seems like I could make one a submodule of the other to ensure that they would both get checked out in one step, though I would prefer not to do that, if possible.
OK, I figured this out. I did not realize that there is the concept of a "workdir" associated with each step that indicates where the "work" happens. The default workdir for all steps is a directory named build.
On http://buildbot.net/buildbot/docs/latest/manual/cfg-buildsteps.html under Source Checkout -> Common Parameters -> workdir, it does acknowledge that source steps are special "in that they perform some operations outside of the workdir (like creating the workdir itself)."
This explains why there is no explicit step that corresponds to a cd command in my above example. To solve my problem, I created two Git steps, each with its own workdir value. This is followed by subsequent ShellCommand steps that call into the appropriate directory, knowing that the two workdir directories will be siblings of one another.
Related
im new using git actions.
So im using actions from git to automate deployment from my repository to my sftp server, everything works fine, but when the action is on execution takes to much time, around 20 minutes, on my repo exist files like system, application, and dist so, that kind of files i don't want to re-upload.
Doing a little research I found out that they can be ignored certains paths.
I found out that they can be ignored with "paths-ignore" but for some reason it's not working, this is my file.
I want to ignore all the content inside application/cache, application/config, application/core .. etc.Or all the folder "application/cache", "application/config".. etc
What am I doing wrong? It's possible to do that?
First I have a suggestion:
Don't put all these files inside your repository, git is for versioning code and not for storage.
paths-ignore is a config for on: event, which means when that on you have changes in your repository, except changes in paths-ignore, start the workflow.
There is no way to reduce too much time in your workflow because every job creates a new machine that gets all your git repository and starts some workflow. But you can read more about the SFTP-Deploy-Action and use the parameter local-path to upload just what you want, maybe your workflow drop to 10 minutes.
I need to build an image for a Xilinx FPGA. Followed these directions. Everything worked and I managed to build it. Now I need to add an extra layer. I thought all I needed to do is to modify .repo/manifests/default.xml (add this layer, https://github.com/sbabic/meta-swupdate/tree/rocko) and then execute
repo sync
but I'm getting errors saying that changes to multitude of files will be overwritten by a checkout (these are the files that were built).
So how do I add a layer to my current environment and rebuild with a new layer without actually rebuilding the whole thing?
cd ./sources/
git clone https://github.com/sbabic/meta-swupdate.git
cd ../conf/
vi ./bblayers.conf
add **{BSPDIR}/sources/meta-swupdate \** before (")
vi ./local.conf
add **IMAGE_INSTALL_append = " swupdate" **
bitbake
How to add Layer example: https://www.youtube.com/watch?v=3HsaoVqX7dg
Is it good practice to edit source code in poky/build/tmp/work directory ? because if we accidentally cleansstate ,the changes will be erased.
Alternatively we can edit source code in "files" directory along with recipe file but since mostly code here is in zipped form due to large number of files , so we will need to unzip and zip again just to change one line of code.
So what is best way to edit source code in yocto ?
If your question is about permanent changes, then Dan's answer is the one to follow. I.e. add a <recipe name>.bbappend to the recipe in your own layer, in which you add
SRC_URI += "file://mypatch1.patch \
file://mypatch2.patch \
"
enumerating all the patches you need.
If there's a large number of patches, it might make sense to fork the upstream repository, and maintain your own branch in your fork. In that case, you'll likely want to reference your own repository, instead of either the upstream repository or tarball.
OTOH, if your question was more about work-in-progress; then sure, doing it in oky/build/tmp/workoky/build/tmp/work/xxxx will work. (And quite likely, it's what most people have been doing for a long time).
However, there's a much better way in recent releases (from 1.8, fido). The new tool is called devtool. You can use it as follows:
devtool modify -x <recipe-name> <path-to-unpack-source>
unpacks the source and creates a new bbappend to build from the unpacked source. It also creates a git repo in the source directory.
Now you can modify the source. You can test-build your modified source by running devtool build <recipe-name>. Once you're satisfied, use git add ... and git commit to commit your changes to the local repo. Once you've commited the changes to the local repo, you can run:
devtool update-recipe <recipe-name>
to update the recipe in question. When you're satisfied, you can run devtool reset <recipe-name> to remove the temporary bbappend.
See also: Yocto manual on modifying source code
If you are continuously "patching" a given package manually, I would recommend you to look at implementing a .bbappend file in a separate layer which applies your patch using the do_patch function (http://www.yoctoproject.org/docs/2.0/mega-manual/mega-manual.html#patching-dev-environment).
How to update sources using jazz scm.
I used this command:
lscm load -r "https://rtcserver.com" workspace
And it downloaded whole repository into current directory. Unfortunately I don't know how to update sources when there is new code checked-in. I tried to use accept command but it doesn't work for me or I'm doing something wrong:
lscm accept -r "https://rtcserver.com" --flow-components -v
This one every time returns "Workspace unchanged." But it is changed!
Edit the files you wish to change. Then use "lscm checkin" to create a change set on your repository workspace, and "lscm deliver" if you want to push that change set back to the stream.
See the online help # http://pic.dhe.ibm.com/infocenter/rtc/v2r0m0/index.jsp?topic=%2Fcom.ibm.team.scm.doc%2Ftopics%2Fm_cli_usecases.html
I've got a project in a git repository that uses some custom (and so far unversioned) setup scripts for the build environment etc. I'd like to put these under version control (hopefully git) but keep them versioned separate from the project itself, while still living in the base directory of the project - I've considered options like local branches but these seem to have the problem that switch back to master (or any other "real" branch) will throw away the working copies of the setup scripts.
I'm on Windows using msysgit so I've got a few tools to play with; does anyone have a recommendation or solution?
If you really need them separate from your main git repo while still living directly within it, you could try:
creating a new repo with those script within it
and:
adding that new repo as a submodule to your repo. Except:
a/ those scripts won't live directly in the base directory, but in a subfolder representing the submodule
b/ you need of course to not publish (push) that new repo, in order for other cloning your main repo to not get those setup files
or:
merging that new repo into your main repo (with the subtree project), but:
you need to split back your project to get rid of those files
for a project with a large history, and with frequent push, that step (the split) can be long and cumbersome.
I would consider a simpler solution, involving some evolution to your current setup files:
a private repo (as in "not pushed") with those setup files
environment variables with the path of your main git repo in order for your setup files (which would not be directly within the base directory of said main repo) to do their job in the right directory (like beginning for instance with a 'cd right_main_git_repo_dir').
I want to share an additional solution and some samples from which to start.
I've has a similar problem in attempting to build Mozilla Firefox with Buildbot -- I need to have some files in the root folder (namely the .mozconfig file and some helper scripts) and I wanted to version them separately.
My solution is as follow:
checkout the Firefox code from the Mercurial repository;
checkout an additional repository with the additional file I need;
before starting the build, I copy these file to the folder with the Firefox code.
This approach is implemented in the following repositories:
buildconfig-mozilla-central: it contains the Buildbot configuration, which
pulls both repositories
copies the files from the scripts repository
and start the build;
buildscripts-mozilla-central: the repository with the build configuration and helper scripts.
Please note that the code might not be well factored (for example the paths) but it should be a good starting point.
This procedure is tailored for Firefox, but it can be applied to any repository.