When I click on the 'builders' link of builbot URL and force a build, the git repository I specify on the form is getting ignored; the builder is using the repository it was originally built/configured with. Is this a known problem ? Is there some way to force the builder to use the new repo ? I'm running 0.8.4 on Ubuntu 10.04. Thanks for any help.
This is a deliberate choice, as there various potential ways of creating a source stamp, that are insecure. Thus, someone could potentially execute arbitrary code on the slave, if buildbot used whatever repository URL passed into it.
That said, it is easy to get the behavior you want. The simplest is to specify
repourl=Property('repository', '<default-repository>')
which will use the 'repository' property of the build (which gets initialized from the source stamp) or the default repository, if none is specified. (Property is imported from buildbot.process.properties)
Related
I have a BitBake/Yocto question. I am building a project which uses Poky and some custom layers added on top of it. While the project is built it outputs "Build Configuration" that includes details like BB_VERSION, BUILD_SYSTEM, DISTRO_NAME, etc. It also has git branch name and version for all included layers like meta-<layer_name> : "<branch_name>:<revision_hash>". I am trying to access branch name and revision for custom layers added from the recipe but could not find a way to get access to it. Also these branch detail variables are lowercase vs other example variables that I listed above are uppercase. I am not sure if that makes any difference as I can access those uppercase variables during build but can't access the ones with lower case.
Would anyone have any clue how can I get git branch name and version via these variables without having to use git commands. Currently I am executing git commands to get those details. I have looked in BitBake documentation and the closest I could find was METADATA_BRANCH variable which gives me meta-yocto-bsp layer branch details.
The part where layers and their versions are printed are done by a function, not from plain variables. Check BUILDCFG_FUNCS for a list of functions that print build configuration data and specifically the get_layers_branch_rev function for the layer data
I am fairly new to Git/LibGit2Sharp and am trying to create a mirror of a git repository using LibGit2Sharp. Following the directions given here: https://github.com/libgit2/libgit2sharp/issues/577, I first mirrored the external repository to a local folder by adding a remote to it, and used repo.Network.fetch(remote, fetchRefSpec) where fetchRefSpec is refs/\*:refs/*
Now, I want to push the data to another remote repository. Here I am confused. Because, when doing this through git commands, you set the remote.remoteName.mirror config entry to true and then do git push remoteName. Specifying any other refSpec when mirror is set to true gives an error.
However, when using LibGit2Sharp, even after I set mirror = true, I still have to provide a pushRefSpec while pushing. Providing empty or wildcard refSpecs throws exception. I even tried refs/tags/\*:refs/tags/*, but I got the same exception. Looping through all branches in the pushRefSpec works, but does not create a mirror.
Has anyone tried this? Is there probably a better way to do this?
The .mirror configuration is an option for the git tool. libgit2(sharp) works at a different level, where you need to specify exactly what you want to push.
At the moment it unfortunately does not support refspecs with a pattern on push, so if you want to push every reference, you'll have to add each of them individually as refspecs for the push.
Buildbot 0.8.6
Periodically the buildbot would fail getting a particular repository. It does this command:
argv: ['/usr/bin/git', 'reset', '--hard',
'26d7a2f5af4b777b074ac47a7218fe775d039845']
and then complains:
fatal: Could not parse object
'26d7a2f5af4b777b074ac47a7218fe775d039845'.
However, the correct command is actually:
argv: ['/usr/bin/git', 'reset', '--hard', 'FETCH_HEAD']
Not only that. The SHA number used in the failed command is from a different repository.
Anyone knows how to fix this?
Thanks so much.
Update:
We have two repositories. We have a GitPoller watching one of the repositories. I would like to have a build run if the watched repository had a push. However, both repositories are needed for the build. The error specified above occurs on the second, non-watched repository. The SHA number in the error is from the watched repository.
Ok, first, let's make sure we have the right understanding:
You're having problem with one builder, that builds 2 repositories
Each build has two git steps which clone two different repositories
You're polling one of these repositories to trigger builds
There is no other scheduler that is triggering builds (or at least not those that fail that way)
What happens when you're polling a repository to trigger builds is that each new build carries with it the changes that triggered it. The git steps refer to these changes to checkout the correct version. You probably need to use codebases to help the two steps distinguish between changes. Unfortunately, codebases were introduced in 0.8.7, so you should consider upgrading. 0.8.6 is ancient.
If upgrading is not an option, pass alwaysUseLatest=True to the Git() step of the repository that you are not polling. That will force it to always use FETCH_HEAD. Here's my shot at that setup:
f = BuildFactory()
f.addStep(Git(repourl='git://github.com/you/polled_repo.git', mode='copy'))
f.addStep(Git(repourl='git://github.com/you/other_repo.git', alwaysUseLatest=True))
The company I work for gave me the project of moving their java project from CVS to Git.
For several reasons, they don't want to use another tool than Eclipse. So we're stuck with EGit.
I know it is possible to configure Eclipse to format code. But it seems like there is nothing that would prevent someone to use his own way of formatting the code.
So my question is, is it possible to refuse a commit with EGit if the code is not formatted correctly ? The reason behind this question is that we want to avoid conflicts due to the code format, which was a really big problem in CVS.
Thank you
I recommend setting the formatter and a save action to format code as a project-specific configuration. Then tracking the .settings directory in Git.
Because it's configured in the project and in version control, developers won't have to configure Eclipse themselves, it's automatic.
We have done this with several projects and if you do it from the start, you will never have any ill-formatted code or discussions about it.
If a developer is really reluctant and even goes as far as unchecking the project-specific formatter and using another one, maybe you should have a talk.
(By the way, a recommended option in the formatter is Never join already wrapped lines, because sometimes the formatter will do weird wrapping. This option makes it possible to have control over wrapping.)
An alternative to checking the code during the commit is a scenario where gerrit is used as review system. The developers would commit their code to gerrit instead of directly to the git repository. Gerrit can then trigger a build job on a Jenkins/Hudson server and that build job can run CheckStyle or any other format checking tool you prefer.
On successful check Jenkins could then also verify the change and merge it into the git repository (most projects prefer Jenkins to only verify the correctness of the code, and a human still needs to review the code afterwards). Commits failing the check would remain in gerrit (and a mail would go to the developer).
The advantage of this approach is that you can do much more than only style checks for each commit, especially run unit tests, static code analysis and code coverage. The major drawback is that you have to set up some more tools than just a git hook.
If you know a way to determine if the code is formatted correctly you can implement this in the hook pre-commit
This hook should be placed in .git/hooks
git comes with a sample, called pre-commit.sample, it either in the hooks directory already or you can find it in the /usr/share/git-core/templates/hooks/ (On Ubuntu).
I have already used some VCS like CVS, SVN and Git. One feature that I am missing cannot be found anywhere.
There are files which I would like to have in the repository but every user should have its own. So when you checkout you get a default of that file and that commit your changes only for yourself.
Why do I want this? There are some files like configuration where I would like to have a default version in the repository (e.g. for building releases or a starting base for new team members) but the changes to that file are only relevant to a certain developer (or working copy) because it will contain paths only valid for that developer/working copy.
Currently when I do not add this files:
- I miss them when creating a new working copy or exporting for a release build
- Have no history which changes I might have done for myself for experimenting
Currently when I add this files to the repository:
- I might never commit them so I have a default in the repository but my file is always flagged "changed". In SVN I can add it to the "ignore-on-commit" changelist to improve a bit.
- I might loose my very own changes of a difficult configuration file (data crash, laptop theft, etc.)
Is there a VCS capable of this? Do SNV or git support something regarding this I might have overseen?
If I understood and decomposed your task correctly
"Have a set of default templates of something, which are starting point of per-user customization and these customized versions must be stored separately and be accessible only by responsible person"
you can use this workflow (draft, subject of modifications and corrections), Subversion based for simplicity and transparent management (strong point of any CVCS really)
Subversion repository
Each user of repo have own predefined path inside repository-tree (with common path-pattern for manageability and easy automation of processes)
One special admin-only managed path also exist, not accessible by ordinary users
Our tree may seems like this (where Repository dir is a root of repository)
z:\>dir /s /B
z:\Repository
z:\Repository\Users
z:\Repository\Template
z:\Repository\Users\Alpha
z:\Repository\Users\Bravo
For every user-path we use Path-based Authentication, which provides access for every and each user only to own subtree in repository,
Template contains (as name assumes) templates stub for all user's documents
Adding new users to repo, obviously, becomes simple and easy automated task:
svn copy Template into new user's dir
add rw permissions for created location for user in authz-file
tell user URL of his personal tree in repo
I don't think the VCS is the problem here. It looks like if you have a file whose contents are dependent on the local environment, you should auto-generate it with a script. This way, you ignore the generated file, but version the script and each developer still gets a perfectly valid copy of the config files at run time. This is the same approach that is used, for example, with user specific IDE settings: .suo files on Visual Studio for example.
Update:
If you specifically need a set of defaults, then the solution is this:
Add the defaults to the repository.
Each dev works in their own branch. This way, they can version the
changes to the config files.
When re-basing onto master and/or merging, the devs simply never
merge their customized configs.
You can always set up a hook to check if the default config has been modified, and if so, maybe email the dev. You simply view such a commit the same as you would view a commit that does not compile.
Devs are smart. Sure, they make mistakes. But never under-estimate the power of some simple communication.
Of course, when the default configs do get overwritten with the customized ones of Dev X, then you use the powers of git to fix that commit immediately.