I know how to include Mercurial hooks in my local repository. This is done by adding
the hook to the hgrc file along with the location of the Python code and the Python hook.
[hooks]
pretxncommit.require_case=python:.hg/require_case.py:require_case
Now I would like to take this hook and add it to the hgrc file located in the central repository. After I do make changes to the hgrc file of the central repository and when I
do a mercurial clone on that repository, the hgrc file does not have my hook definition.
This central repository is running under a Linux environment.
Am I missing anything in the steps. Any advice is appreciated. Thanks.
The hook entries don't transfer between repositories, none of the details in hgrc do.
See http://www.selenic.com/mercurial/hgrc.5.html
under "Files"
<repo>/.hg/hgrc
Per-repository configuration options that only apply
in a particular repository. This file is not version-controlled, and
will not get transferred during a "clone" operation. Options in this
file override options in all other configuration files. On Plan 9 and
Unix, most of this file will be ignored if it doesn't belong to a
trusted user or to a trusted group. See the documentation for the
[trusted] section below for more details.
Related
How to config the _data folder to another git repository? The whole folder is clone from github and want to continue due to easy update. But the _data folder need to sync with another data repository. How can I config it?
Actually just one yaml file : _data/authorlist.yaml
What to put into package.js if want a script to sync the yaml file with github?
Thank you.
You can use Git submodules to keep a shared repository of data files that you can use in multiple projects. This will allow you to keep a reference to the data repository in your projects, and pull updates to this repository with a single command. The great thing is that submodules are a built-in feature of Git, so it's independent of any NPM scripts, environments (like a bash script would be) or frameworks. See the link above for documentation on how to set up and work with submodules.
I have a file name settings.py. In my host machine settings.py has a different configuration with that of other developers. I want to stop git from tracking settings.py but not to delete this file from other developers machine when ever they pull changes in the project
Some people talk about including the file in .git/info/exclude folder.
But i have no idea as where to locate this file. I searched for it in my project folder( where git has been initialize). To no avail.
expected result
When ever i commit changes, all changes are push to master except my settings.py file, but not deleting this file from other developers machine when ever they pull my changes.
You already mentioned the correct answer. You can use .git/info/exclude as also documented here.
If you have not created this file yet, you can do so now. Simply place a text file called exclude in .git/info. The .git folder should be present already in the root of your repository.
The file uses the same syntax as a regular .gitignore file, but will only be applied to you.
You can also manually specify a core.excludesfile as described in this answer:
git config --global core.excludesfile ~/.gitignore
I used computer A via the Terminal to create a) create a git repository, b) add an index.html file to the repo, c) add a remote origin, d) push to the remote origin. All OK.
Then, i used computer B to clone that repository via Terminal. Then, I opened Eclipse (equipped with Egit), and created a new project in the folder that was created by the cloning process. Then I used Eclipse to push any changes to the remote origin.
Returning to computer A, I used Eclipse to create a project in the original repo folder, and then I attempted to pull from the remote origin, in order to get the changes that were pushed when using computer B.
Eclipse will not do it. It complains the I have items such as .settings, .project and similar and since they are not under version control it won't overwrite them by fetching files from the server. I had to manually delete those files (via Terminal) and then Eclipse worked as expected.
Please provide information on how to avoid this.
Should I create the local repo from within Eclipse and then push it to the remote origin, so that items such as (.settings) are under version control and (if so) how would that cause trouble to people cloning the repo and use different versions of Eclipse?
Should I gitignore those items?
Should I ask Eclipse to save its own affiliated files to another folder (not that i am aware how to do that, i only know that NetBeans does it)?
Looks like you didn't gitignored eclipse files.
Probably, when you commit/push via egit, you also commit and push those files you already had unversioned in your machine A, so git complains, because you are asking to override existing unversioned files.
I strongly recommend you to gitignore those eclipse files. You can see examples of .gitignore files in the github gitignore repo.
Hope it helps.
It complains because if you pull the changes from your remote it will overwrite your local files. That is the problem. The other answerer has right. You should better add all the eclipse project files and and target .settings and classpath to gitignore. You can use a global gitignore for your computers as well, before creating projects. You could use maven for example, then you can import your projects only from the pom.xml-s given in the git repository.
I use them the same. Egit and other guis are a bit too complex to work with. Git repositories can get easy in an inconsistent state where you should use the oldfashioned terminal to solve things. Like, rebasing, merging on conflicts. Gits learning curve is solid.
Now you can solve your problem if on the first computer save a backup of your original and clones your project later, after fixed it on the second. On the second git remove all this files, but use the --cached option to avoid deleting them. Before you do it so, check the help of git remove! after you have done this, put them into the .gitignore as filenames with wildcards. You can also use a global gitignore file in your user folder. Creating a .gitconfig file where you can specifiy the global ignore with the following :
[core]
excludesfile = ~/.gitignore_global
Than just create the .gitignore_global like this :
/nbproject
/bin
/build.xml
.idea
chess.iml
target/
bin
( This file is for idea and netbeans. you can add eclipse project files here )
You can have .gitignore files per project too. You can commit them to the repository, so on the next machine you do not have to do this again. The nicest way I think is having a dotfiles git repository, which is a git repo of your home directory and the dotfiles in it. I also use it for different windows and linux distros.
That's all. You should keep all of your configuration in a safe place. And source code management can do it. But do not commit private stuff to public a place! ;)
Oh I wanted to mention that, you can also have a .gitignore entry in your .gitignore file. That can be very useful when you do not want to touch a repository but need to add a gitignore to hide some stuff especially from the given repo.
I have a setup as follows.
A private repository at bitbucket where I keep the 'master' repository.
A repository on my server which acts as the 'live' website.
A repository on my laptop which acts as my working copy.
My process is as follows. I make a change to a file in my local repository. I commit these locally. I push these changes to bitbucket. I then pull these changes from my bitbucket to the webserver.
The problem that I have however is that my local copy utilizes different configuration settings for databases, paths etc, ergo what I want is my 'config.php' file at bitbucket to contain the server settings, and the config.php on my local host to contain local settings.
I believe this can be achieved with .hgignore but i have had no success researching.
The problem i encounter is that i make my server settings file, push it to bitbucket, 'forget' the file in my local repository, create a .hgignore, and then recreate the file. However when i 'forget' the file TortoiseHG notices and asks me to commit the change to bitbucket....
Any ideas would be greatly appreciated.
Thanks
Additional Points.
Following the advice below I have developed a setup as follows:
I have my local repository on my laptop where i do my edits.
I have bitbucket which is essentially the 'main' repository - if any other developers join the team they clone this.
I have my live repository on my web host.
On my live repository I have a .hgignore file whichs ignores the respective config files.
As such when I do hg pull from my host, it pulls the repository as is with the localhost configuration files, but when i type hg update (to the live working copy), these files are ignored/not updated.
Could someone clarify as to if i have understood this correctly, and as to whether this is a suitable way of achieving what I want?
Thanks
.hgignore only ignores files if they are not versioned already, so I don’t think your idea in the question will work.
The common approach regarding local configuration is generally a variation on the same theme, like of one of the following:
Do not check in the config.php at all. You can check in a config.example.php with the most common settings, and document in the README that users have to copy it to config.php and then edit it.
Put any shared settings in config.php, and add an include statement to point to an unversioned file with settings specific to the machine, e.g. config.local.php. You can also provide an config.local.example.php-file for this.
Like 2, but the config.php contains all default settings and the local file has the ability to override them.
Check in a config.dev.php and config.server.php-file containing the settings for both environments, and then have an unversioned config.php which includes one of the above files. Advantage is that the configurations themselves are versioned and you can update them.
Which of these variations to pick, or whether you make another variation, depends on your environment.
The basic idea for working with version control and different configuration files is always the same, but I don't know enough PHP to give a detailed answer how you can do this in PHP.
I answered a similar question for .net/Visual Studio a few months ago, so I'll just give you the link to this answer and try to describe the basic idea again, but this time language-agnostic:
For your use case, the basic idea is to have two config files in the repository, one with your local data and one with your server data, for example like this:
config.local.php
config.server.php
The "real" config.php is not in the repository, and it should be in .hgignore, so it never will be in the repository either.
After pulling, you need to run something that copies one of these files (the "correct" one depending on the current environment, local or server) to config.php.
And exactly this last part is the part that I can not answer in detail, because I don't know how to do that in PHP and/or on a web server because I'm a .net/Windows guy.
As far as I know, deploying a PHP site is just copying the files on the web server, so there is no "build/compile" step where the copying/renaming of the config file could be done (where I would do it in .net). Correct me if I'm wrong...
EDIT:
Thomas, I'm not sure if I understood your edits correctly. Your "local" repository on your laptop and your "live" repository on your webserver are basically clones of your "main" repository on Bitbucket, correct?
If yes, are you saying that you have different .hgignore files in the different clones?? That's the part that confuses me.
No matter how you actually do it in the end (there are several possibilities to deal with configuration files, see below), the .hgignore file should be the same in all clones of your repository.
So all your repositories (no matter which clone on which machine) should all contain the same configuration file(s).
Then, you only need to make sure that different configurations are used in different environments. There's already an excellent list of different ways to achieve this in Lauren Holst's answer, so I'll just point you there.
As Laurens Holst already said, we can't tell which of these ways is the best for you - it depends on your environment.
You might want to check here. If both the config file and .hgignore are commited, the .hgignore will have no effect. You could also add a domain check conditional:
$domain = $_SERVER['HTTP_HOST'];
if ($domain=="localhost") {
//local copy config
}
else if ($domain=="yourdomain.com") {
//webserver config
}
I am new to Hudson / Jenkins and was wondering if there is a way to check in Hudson's configuration files to source control.
Ideally I want to be able to click some button in the UI that says 'save configuration' and have the Hudson configuration files checked in to source control.
Most helpful Answer
There is a plugin called SCM Sync configuration plugin.
Original Answer
Have a look at my answer to a similar question. The basic idea is to use the filesystem-scm-plugin to detect changes to the xml-files. Your second part would be committing the changes to SVN.
EDIT: If you find a way to determine the user for a change, let us know.
EDIT 2011-01-10 Meanwhile there is a new plugin: SCM Sync configuration plugin. Currently it only works with subversion and git, but support for more repositories is planned. I am using it since version 0.0.3 and it worked good so far.
Note that Vogella has a recent (January 2014, compared to the OP's question January 2010) and different take on this.
Consider that the SCM Sync configuration plugin can generate a lot of commits.
So, instead of relying on a plugin and an automated process, he manages the same feature manually:
Storing the Job information of Jenkins in Git
I found the amount of commits a bit overwhelming, so I decided to control the commits manually and to save only the Job information and not the Jenkins configuration.
For this switch into your Jenkins jobs directory (Ubuntu: /var/lib/jenkins/jobs) and perform the “git init” command.
I created the following .gitignore file to store only the Git jobs information:
builds/
workspace/
lastStable
lastSuccessful
nextBuildNumber
modules/
*.log
Now you can add and commit changes at your own will.
And if you add another remote to your Git repository you can push your configuration to another server.
Alberto actually recommend to add as well (in $JENKINS_HOME):
jenkins own config (config.xml),
the jenkins plugins configs (hudson*.xml) and
the users configs (users/*/config.xml)
To manually manage your configuration with Git, the following .gitignore file may be helpful.
# Miscellaneous Hudson litter
*.log
*.tmp
*.old
*.bak
*.jar
*.json
# Generated Hudson state
/.owner
/secret.key
/queue.xml
/fingerprints/
/shelvedProjects/
/updates/
# Tools that Hudson manages
/tools/
# Extracted plugins
/plugins/*/
# Job state
builds/
workspace/
lastStable
lastSuccessful
nextBuildNumber
See this GitHub Gist and this blog post for more details.
There is a new SCM Sync Configuration plug-in which does exactly what you are looking for.
SCM Sync Configuration Hudson plugin
is aimed at 2 main features :
Keep sync'ed your config.xml (and other ressources) hudson files with a
SCM repository
Track changes (and author) made on every file with commit messages
I haven't actually tried this yet, but it looks promising.
You can find configuration files in Jenkins home folder (e.g. /var/lib/jenkins).
To keep them in VCS, first login as Jenkins (sudo su - jenkins) and create its git credentials:
git config --global user.name "Jenkins"
git config --global user.email "jenkins#example.com"
Then initialize, add and commit the basic files such as:
git init
git add config.xml jobs/ .gitconfig
git commit -m'Adds Jenkins config files' -a
also consider creating .gitignore with the following files to ignore (customize as needed):
# Git untracked files to ignore.
# Cache.
.cache/
# Fingerprint records.
fingerprints/
# Working directories.
workspace/
# Secret files.
secrets/
secret.*
*.enc
*.key
users/
id_rsa
# Plugins.
plugins/
# State files.
*.state
# Job state files.
builds/
lastStable
lastSuccessful
nextBuildNumber
# Updates.
updates/
# Hidden files.
.*
# Except git config files.
!.git*
!.ssh/
# User content.
userContent/
# Log files.
logs/
*.log
# Miscellaneous litter
*.tmp
*.old
*.bak
*.jar
*.json
*.lastExecVersion
Then add it: git add .gitignore.
When done, you can add job config files, e.g.
shopt -s globstar
git add **/config.xml
git commit -m'Added job config files' -a
Finally add and commit any other files if needed, then push it to the remote repository where you want to keep the config files.
When Jenkins files are updated, you need to reload them (Reload Configuration from Disk) or run reload-configuration from Jenkins CLI.
A more accurate .gitignore, inspired by the reply from nepa:
*
!.gitignore
!/jobs/
!/jobs/*/
/jobs/*/*
!/jobs/*/config.xml
!/users/
!/users/*/
/users/*/*
!/users/*/config.xml
!/*.xml
It ignores everything except for .xml config files and .gitignore itself.
(the difference to nepa's .gitignore is that it doesn't "unignore" all top-level directories (!*/) like logs/, cache/, etc.)
The way I prefer is to exclude everything in the Jenkins home folder except the configuration files you really want to be in your VCS. Here is the .gitignore file I use:
*
!.gitignore
!/jobs/*/*.xml
!/*.xml
!/users/*/config.xml
!*/
This ignores everything (*) except (!) .gitignore itself, the jobs/projects, the plugin and other important and user configuration files.
It's also worth considering to include the plugins folder. Annoyingly updated plugins should be included...
Basically this solution makes it easier for future Jenkins/Hudson updates because new files aren't automatically in scope. You just get on the screeen what you really want.
Answer from Mark (https://stackoverflow.com/a/4066654/142207) should work for SVN and Git (although Git configuration did not work for me).
But if you need it to work with Mercurial repo, create a job with following script:
hg remove -A || true
hg add ../../config.xml
hg add ../../*/config.xml
if [ ! -z "`hg status -admrn`" ]; then
hg commit -m "Scheduled commit" -u fill_in_the#blank.com
hg push
fi
I've written a plugin that lets you check your Jenkins instructions into source control. Just add a .jenkins.yml file with the contents:
script:
- make
- make test
and Jenkins will do it:
I checked in hudson entirely, you could use this as a starting point https://github.com/morkeleb/continuous-delivery-with-hudson
There are benefits to keeping entire hudson in git. All config changes are logged and you can test the testup quite easily on one machine and then update the other machine(s) using git pull.
We used this as a boilerplate for our hudson continuous delivery setup at work.
Regards
Morten