I have repositories in BitBucket and I am satisfied and do not want to change it to another cvs.
But I want to use some free CI service for my projects.
Things I tried:
PhpCI, but PhpCI is bad supported
Jenkins, but it is too complicated for me
That's why I started researching Gitlab CI.
I saw that CI is a part of gitlab (https://about.gitlab.com/gitlab-ci/).
But maybe somehow I can use just CI and do not use another features.
Is it possible?
You can't use GitLab CI without GitLab, but no one forces you to use any of other GitLab features if you don't want to.
Git is distributed and you can have your source pushed to multiple destinations.
Just define it in your project's .git/config as another destination for push, for example:
[remote "origin"]
url = git#bitbucket.org:user/project.git
pushurl = git#bitbucket.org:user/project.git
pushurl = ssh://git#gitlab.yourdomain/user/project.git
fetch = +refs/heads/*:refs/remotes/origin/*
Then add .gitlab-ci.yml, push, and GitLab CI will run, while your source will be both in BitBucket and GitLab (which you will use only for checking the CI pipeline).
Related
we want to add a tag after merge_request approve/merged in default develop branch
after add this dev version tag, we also want to do source code complie
once complie passed, save target build to local server for test purpose.
seems gitlab still not official support it, is there any unofficial API or good solution to do it?
the most important part is how to trigger this job after merge_requst.
Thanks
To solve this flow I would suggest the following general approach:
create a job that only runs on develop branch and creates a git tag: git tag $TAG_NAME && git push --tags
create another job that also only runs on the develop branch, but needs the job from point 1 and does the code compiling
create a third job that needs job from point 2, only runs on develop and copies the artifact via scp, sftp or similar method to the local server you mentioned.
The essential part is running the CI job on the develop branch as this is the only option to hook into after the merge.
Some documentation that will help you create the specific solution you need:
only -> https://docs.gitlab.com/ee/ci/yaml/#only--except
needs -> https://docs.gitlab.com/ee/ci/yaml/#needs
about ssh (sftp/scp) on gitlab -> https://docs.gitlab.com/ee/ci/ssh_keys/#ssh-keys-when-using-the-shell-executor
git tag -> https://git-scm.com/docs/git-tag
git push -> https://git-scm.com/docs/git-push
about git push in gitlab-ci -> https://docs.gitlab.com/ee/topics/git/tags.html
I'm trying to set up a CI job that require dependent repositories to be placed along side the repository for which I'm enabling CI. By dependent, I mean that my main repo needs the code in the dependent repo but there is no build or test dependency between the two repos
I find a way to clone a dependent repository using this command in the job's script
git clone https://gitlab-ci-token:${CI_JOB_TOKEN}#gitlab.mycompany.com/path_to_my/dependent_repo.git
The problem is that the repo is fresh cloned every time the job runs which takes way too long as the dependent repo is quite large.
Is there a way to "fetch" a dependent repo as efficiently as GitLab CI fetches its own repo (against which CI will run), basically performing a pull instead of a clone?
Should I use cache?
If you have one main repo that depend on a few other repos, I would add these as submodules. This makes it easier to handle in GitLab, and your colleagues can easily find the correct versions they need to clone for these repos. If you have some specific need to not have these as submodules, then I understand!
In GitLab, there are a few different ways of handling this. The most simple one is to use the GIT_STRATEGYvariable:
https://docs.gitlab.com/ee/ci/yaml/#git-strategy
You can set it to fetch like this:
my_job:
variables:
GIT_STRATEGY: fetch
script:
- echo test
GitLab will then try to reuse an existing working directory instead of always cloning a new one.
I had a case myself when I used a flag for git clone called --reference:
https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---reference-if-ableltrepositorygt
It has some very strange special cases that you have to think about. What the flag does is that git uses a local copy of a repository and copies objects from that one, instead of always copying from the network. This can greatly speed up cloning operations in some cases.
In addition to these suggestions, GitLab has a page with their suggestions to handle large repositories:
https://docs.gitlab.com/ee/ci/large_repositories/
My requirement is whenever developer try to do check-in existing GitLab repository then before doing check-in in repository,build should trigger (Jenkins build) and Junit test case should run on new check-in and if passes then it should go forward and will allow developer to do check-in in main repository.
I am not sure but is pre-hook commit can achieve this requirement?
While you could achieve this with pre-commit hooks, it's more common to do so with post-commit hooks on the server-side.
You can achieve this by operating a branch based workflow, there are multiple to choose from - I would recommend reading through this guidance by Atlassian.
Developers will create branches from a 'main' branch (often master, but can be a 'dev' branch working towards a release for instance), then develop code on that branch. They will then push their branch and commits to the remote repository (GitLab). When ready to merge into the main branch, your developers can open a merge request onto the main branch.
On GitLab you can setup a webhook to trigger Jenkins builds when a push event occurs. I would recommend this guide to guide you through it.
In the GitLab project settings you can require a passing build before merge requests are allowed to merge.
Furthermore, your understanding of Git seems incorrect - check in is not a term used in Git. Please take a look at the Git documentation. In Git a developer creates commits against a local copy of the repository, then pushes these to a remote repository (GitLab/GitHub etc.). There is no direct equivalent of the 'check in' used in various centralised version control systems e.g. SVN.
I recently moved a repo from bitbucket to gitlab. I now want to have a CI (travis or drone) working with my repo.
After some reading, i found out that gitlab builded their own CI (gitlab CI) but needed to be self hosted and it dont seem to be possible to set on heroku.
I dont want to manage an AWS instance only to get a CI server, as travis, drone (and probably some other that i dont know of) already exist and do the job.
Is there something i missed? Is there a way to have (quick and easy) gitlab CI (i repeat that i wont take a self-managed server for this) or i will have to move to github or get back to bitbucket?
Gitlab is really a nice product, but the lack of support for CI server is a road block!
Thank you
It seems that Drone already does GitLab: http://feedback.gitlab.com/forums/176466-general/suggestions/5675077-integrate-docker-drone-with-gitlab-ci-runner but I haven't tried it.
You might also have a look at: https://githost.io/, it manages GitLab and / or CI for you, and you can connect the CI to any GitLab instance: https://githost.io/docs#ci_master Since you already have the CI there, keeping it in-house is not a concern, so you might as well also have the GitLab instance there or at gitlab.com It was acquired by GitLab in 2015 Q2 https://twitter.com/gitlab/status/592438051533524993
Travis on the other hand seems to be bound to GitHub and thus not an option: Integrate Gitlab and TravisCi
As mentioned by Dorum, Magnum CI also handles GitLab: https://magnum-ci.com/docs
MagnumCI now support Gitlab and other popular platforms. Also Gitlab launched the own CI service with shared servers.
We're using GitLab for our project and we think it's great.
We're also using git flow to manage the changes in feature, develop, master branches.
Can you use the Merge Request build in GitLab to manage the branches in git flow style?
Meaning when accepting a Merge Request for a release branch, it will merge the release branch into master AND into develop..
Or should we always use git flow on our local machines to accept the Merge Requests.
Like this issue 1628 illustrates, it is best to use GitLab to publish (push) branches, then to rely on a specific GitLab feature related to a particular workflow like git-flow.
So the natural approach is to limit those git-flow features to the local clones, and push any branch you want to GitLab once the merge request is resolved.
By now, there is something called GitLab Flow, "a clearly defined set of best practices".
Cited from the linked source:
It combines feature-driven development and feature branches with issue
tracking.