Is there a way to connect a GitLab project with Github? I mean when I push or make any modification to the Gitlab project it should be done automatically to another same copy in Github.
Is there a way to do that?
Yes there is. Gitlab offers Repository mirroring out of the box for all tiers:
Repository mirroring allows for the mirroring of repositories to and from external sources. You can use it to mirror branches, tags, and commits between repositories. It helps you use a repository outside of GitLab.
A repository mirror at GitLab updates automatically. You can also manually trigger an update at most once every five minutes on GitLab.com with the limit set by the administrator on self-managed instances.
There are two kinds of repository mirroring supported by GitLab:
Push: for mirroring a GitLab repository to another location.
Pull: for mirroring a repository from another location to GitLab.
I use this to synchronize my repos between Github and Gitlab and works fine for me
Related
Is this a possibility to integrate github repository in gitlab.
My basic need is to commit in github and flow it all in gitlab.
I am not sure if this can be done!
Is this a classical case of CI?
Thanks!
I think you want to do some mirroring of your project. I guess (but not tested) that if the repository have a .gitlab-ci.yml file, pipelines will be launched when commits are mirrored.
My problem is I have mirror repository on GitHub, that I can't commit into. I have to run some pipelines on this repo. In GitLab CI, it's possible to select CI/CD configuration file from another repo. I searched throught actions repo settings, but I couldn't find anything that would help me. Is that possible in GitHub Actions? Or I have to find some workaround?
I'm wanting to fork a github repo into AzureDevOps, whilst retaining the capability within AzureDevOps to keep pulling changes from github as-per forking a repo within github.
Is this feasible / on a roadmap?
I'm wanting to fork a github repo into AzureDevOps, whilst retaining the capability within AzureDevOps to keep pulling changes from github as-per forking a repo within github.
I am afraid there is no such out of box function of the "Fork" in GitHub for Azure Devops. But you can import repository from GitHub directly.
In Azure DevOps the project you want to clone the repository or create a new team project, click code tab. Click repository menu in Code Tab (it is on the top left side) and select Import repository:
Then, slect the SourceType GIT and add your github repository URL:
However, according to the ticket on the github:
Currently there is no Azure DevOps' build in support for automatically
updating your GitHub repo fork in Azure Repos.
We need do the sync manually on the dev machine.
Besides, there is an old document about How-To Fork Git Repositories on Visual Studio Online, but we still need to create a middleman to moderate changes from GitHub before pushing them into a VSTS project.
Hope this helps.
Let's say I have an internal web server (nginx) and I want it to serve a page with the content of the GITHUB repository, e.g. https://github.com/vibranze/test. Page from the repository must be served locally.
I've tried the article from https://help.github.com/articles/duplicating-a-repository/ but the synced repository is not browseable due to no index file.
How do I make the local repo browseable internally and looks exactly the same like what its master copy in github.com or if I've done it wrongly, what's the correct way to achieve it?
Any pointer or advice are greatly appreciated.
Thank you.
Short answer:
You need a local Git server which hosts a clone of your example repository from GitHub.
If your local Git server includes a web UI, you can probably see something similar like what you see on GitHub.
If you want future changes in the GitHub repo in your local repo as well, you need to pull periodically from the GitHub repo to your local repo.
Long version:
1. Hosting Git repos on your local server
There are a lot of options (paid and free) for running a Git server on your own machine.
Some of them contain web UIs which look similar (but not exactly the same) like GitHub.
There's only one option to get 100% the same look: by spending money for a private installation of GitHub (but it's not cheap).
If you don't want to spend that much, there are free alternatives, for example GitLab. This is a hosted service like GitHub, but the code is open source and you can install a free version on your local server.
Here's an example of a "repository overview" page:
https://gitlab.com/gitlab-org/gitlab-shell
GitLab is only one example, there's a lot more - just google for "self hosted git" and you will find plenty.
2. Getting a clone of the repository from GitHub to your local server
To set this up, clone the repo from Github to your local machine once with the --mirror option:
git clone --mirror https://github.com/user/repo some/local/path
To update your local repo with the newest changes from GitHub, you need to run git remote update periodically.
I want to set up a staging server where each developer will have his own docker container running the app and Jenkins .
I want each one to be able to connect his github branch with his jenkins server with the github plugin for jenkins and create the automated build pipeline. But every branch will be in the same corporate private repository.
Push code from IDE -> Code goes on Github -> Github pushes to jenkins(in container) -> jenkins builds new code(in container) -> tester connects to container and browses the app branch
I have made 2 containers each with a jenkins server. One is connected with master branch and the other with branch1 of the same repo. But each repo allows only one implementation of the github plugin for jenkins.
Setting one new repo for every branch seems kind of silly and wasteful.
Best case scenario would be to connect many jenkins servers with the same repo but on different ports by specifying different branches.
Is something like this possible?
If those docker container can mount the same data container with the git repo in it, that means they can checkout different branches per repo.
For that, they need a recent git (2.5+) and to use the new git worktree add command.
Then those containers would work in a worktree set to a different branch per container, but all pointing to the same repo.