My Jenkins pipelines use the GitHub SCM module, which checks out my repo using git clone.
Recently though, I've been seeing frequent build failures due to intermittent network performance issues, leading to git clone timing out.
One solution would be if I could pull the repo down as a zipped archive instead, this would drastically reduce the download time.
My questions are:
a) Is this advisable (compared to using git clone)?
b) How would I do this to get the same effect as git clone
c) is it possible to do this using the Git SCM plugin or similar plugin?
Thanks in advance for any advice!
If is a network problem you should fix the network problem.
But, if you can't maybe the solution is increase git clone timeout.
Again, the best solution is fix the network.
Related
My team works with Bitbucket > Sourcetree. We are having problems cloning the repository, possibly due to size and network, but some others have the repositories from past. Can they zip and send it to us? What other solutions/options are there?
I have a small embedded linux system image which I deploy for users. It has a Python project on it that checks github using git ls-remote --heads for changes and does a git pull to pull the latest version.
There is no need for writing anything to the repository, it's actually better if that's not possible, since these systems are outside of my control. Because of that I also don't like to put my own Github credentials on it.
Is it possible to use Github in this sort of semi-public manner?
If so, what would be a good minimalistic (i'm guessing SSH) setup?
(by the way, this used to work, but recently stopped working, I've not figured out why yet. I have never before set up any key's or whatever, so i'm guessing this should be possible..)
You can just clone the repo:
git clone git://github.com/SomeUser/SomeRepo.git
The local repo will be "read-only" in the sense that you won't be able to push your changes back to the remote repo. You will still able to modify files and commit changes locally.
Use HTTPS (https://help.github.com/articles/which-remote-url-should-i-use/)
Configure git as follows to suppress the self-signed cert warning: git config --global http.sslVerify false
Our team is looking to migrate our perforce server over to Git. Is there a way to sync check-ins from a branch in our Github Server back to Perforce to keep them in sync? I have been looking at git-p4 and there seems to be lots of documentation of how to sync Perforce -> Git but not the other way around. I would ideally like to have it syncing both ways perforce <-> git, is that possible with p4-git?
Perforce GitFusion can do this, but the developer would have to push changes to the GitFusion server instead of the github server.
For most of the time, merge conflicts were sorted out automatically. Perforce was the "master". People submitting from Perforce always had their change go straight through. People submitting from git would have their change submitted via this process:
lock master git repo
fetch upstream p4 changes
rebase against upstream p4
submit to p4 if that all went ok
That still left a very small window between (3) and (4) where someone in Perforce land could submit a conflicting change to the same files. But in practice that only happened a couple of times, over the course of several years of probably hundreds of commits per week.
In those two cases I went in and manually patched things up which was a bit clunky. I think you could just automatically discard the problematic change quite easily, but in the end, switching to git entirely made this problem go away.
Git-p4 is designed such that the git repository is initialized with data imported from Perforce. After this initial import bidirectional communication between git and Perforce repositories is fully supported, with the exception of branches/merges that have limited support.
To import updates from Perforce to git:
git p4 sync
To submit changes from git to Perforce:
git p4 submit
For more details regarding git-p4 configuration please consult its documentation.
Update: I would always advise to test any flows in temporary repositories before deploying.
In the past I setup something like this. I had a gitolite repo and a p4 server. Changes pushed to the gitolite repo would be picked up by a cron job and turned into P4 commits (via git-p4 submit). Similarly, changes submitted to p4 would be picked up by the same cron job and synced back to git (via git p4 rebase).
There were two git repos involved: the gitolite repo that normal git developers committed to, and a separate git-p4 based repo where the git-p4 operations took place.
I had a fairly small shell script to co-ordinate everything. The main tricky areas were:
locking: you have to forcibly rebase the gitolite repo so you need some way to ensure developers don't lose changes when this happens (I used a lock file).
Merge conflicts. Very occasionally two people would edit the same section of a file in P4 and git at the same time.
I have faced this problem myself and as far as I know there's nothing of the kind.
In my case I have to basically:
Create a patch for the changes in Git: git diff sha1..sha2 > mypatch.diff
Make a list of the affected files: git diff --name-only sha1..sha2 > files.list
Apply the patch in the P4 repo: git apply mypatch.diff
Reconcile changes in P4: for each file in files.list; p4 reconcile $file; done
Edit your P4 change list and then submit it (I'm sure this can be automated too but I haven't had the need for it).
I have a couple of scripts that help me with this, you can find them here: https://github.com/pgpbpadilla/git-p4-helpers#sharing-changes-git-p4
I have been using this workflow for ~6mo and it works for most cases.
Caveats
This creates a single change lists for all commits in the sha range (a..b).
I'm coming from a perforce background, trying to understand gitHub.
In Perforce when I "checkout" something it lets other users know I am working on that file. Does checkout work the same way in Git?
It seams like you don't check out files but branches?
Thanks
checkout in Perforce would roughly equate to clone in git, but in VCS like git ( and even SVN ), the checkout doesn't signal lock to others that you are working on it. Anyone can clone a git repo and work on it without thinking about who else is working on it.
In general, checking out a branch does not mean anyone gets notified. It simply means you are switching from one branch of code to another, potentially also creating a new branch in the process depending on your arguments.
For more info about checkout, see git checkout documentation.
I am trying to find the right way to do this. My firm is using SVN as we are working on the projects to do checkin and checkouts. But I am thinking about using Git to backup all my work as I got home.. here is why
From Home I don't have access to my firms SVN Repo so I was thinking about setting up a Git Repo on the internet to checkin all my work into git before I leave work so I can access it from home.
I would like to hear if others are doing this and if you think this is a good practice.
How would I do this? I been using SVN and Eclipse for sometime now but I hear GIT would be better for cloning my workstation...
The solution to this for many people is 'git svn'. It allows you to create a local git repo as a clone of a tree in svn, work locally, and commit your work back to svn.
You can run git svn while at work, copy the resulting repo to a disk you carry home, and then commit back to svn when you get back to work. Always assuming, of course, that your employer's policies permit this. If you can't get to svn from home, perhaps they don't like anything about this idea.