I want to add a few config files to .github folder but I can't seem to find it in my repository. I do see the .git and .gitignore files. Where can I find this .github folder, Is it added by git or should I create it?
There isn't one unless you create it (and if you do, you should create it in the root directory for the repository).
i made a clean installation of visual studio code. Why do i get those warnings about Git 99+ warnings. How should i fix this ?
Those are Atom IDE generated files.
Add this to the .gitignore file:
.atom/
If the file not exists, create one in the root of the repository
It looks like you just forgot to ignore all of the generated files in your git directory. You need to find the directory and add it to your .gitignore file. Lets say the directory name is node_modules, so your .gitignore file content should be something like this
node_modules/
Using this way, those all active changes files will be ignored.
If a user sees that message it is most likely, that his git repository root is at the different directory, and probably is at the much higher directory (comparing to his/her repo). It can be checked by running:
git rev-parse --show-toplevel
If that's the case, then deleting hidden folder .git from this higher directory will solve the case.
I use the latest version of Github Desktop. My repo consist of a rather large C# solution with many sub-directories and projects. I'd like to ignore all R#-cache files and compiled binaries using the .gitignore file which resides in the root directory of the local repo directory. There are no other gitignore's anywhere in this repo and none in any parent directories. My current gitignore is this:
*.suo
*.user
_ReSharper.*
bin
obj
packages
*.cache
*.pdb
*.dll
*.exe
*.xml
When I made my changes, recompiled and tested everything, I open Github Desktop. It catches almost all files that should be ignored, only some .dlls, .pdbs and .exes are not ignored and always show up as changed:
Now, there are way more binary files in this repo. Only the specific ones in the screengrab are missed.
Is this fixable, and/or can the gitignore be altered to catch all files that it should catch?
Here's what I tried:
Removed and re-cloned the repository
Removed and manually re-created the gitignore
Right-click->Ignore by file extension from within the GitHub Desktop client. This does not work, worse, it creates duplicate masks in the gitignore
Checked for conflicting gitignore's in directories accessible by Github Desktop
Maybe you have files that were already being tracked by git before you modified the .gitignore? Those files (at least in git 1.9.1) aren't ignored when added to a .gitignore.
For example, I created a "test" directory at the root file one of my repos and put a file in it:
mkdir test
echo "abc" > test/x.txt
I added, committed and pushed it. Then I edited .gitignore at the root and added this line:
x.txt
I also made an edit to test/x.txt AND added a new file:
echo "123" >> test/x.txt
mkdir test2
echo "xyz" > test2/x.txt
Now when I run "git status" I see:
modified: .gitignore
modified: test/x.txt
So test2/x.txt is being properly ignored, but test/x.txt is still being tracked.
To force the file to be ignored, you can delete it, add & commit the deletion together with the .gitignore change, then restore the file.
Every GitHub repo has the Download ZIP button, but is there a way to control what gets into the final zipball. For example we do not need and hidden files there, or even - unit tests.
Excerpt from Pro Git book:
You can tell Git not to export certain files or directories when
generating an archive. If there is a subdirectory or file that you
don’t want to include in your archive file but that you do want
checked into your project, you can determine those files via the
export-ignore attribute.
For example, say you have some test files in a test/ subdirectory, and
it doesn’t make sense to include them in the tarball export of your
project. You can add the following line to your Git attributes file:
test/ export-ignore
Now, when you run git archive to create a tarball of your project,
that directory won’t be included in the archive.
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