We are using Gitlab Community Edition 8.15.2 and are using custom global git hooks for all our repos (i.e. all repos use the same hooks).
For one of our repos, I want to use a <project>.git/custom_hooks hooks and NOT the global hooks.
According to the Gitlab documentation for chained git hooks (https://docs.gitlab.com/ce/administration/custom_hooks.html) it's going to go through all the possible locations and execute as long as the previous ones successfully exit.
I don't want it to execute both the custom_hooks and the global hooks...just the custom one. Is this possible?
The problem is, after gitlab-shell merge_requests 93, that <project>.git/hooks/ is a symlink to gitlab-shell/hooks global dir.
So if you want to be sure to not use global hooks, you would either
change the symlink to an empty folder (but that might have side-effects if gitlab-shell expects to run for instance a common global pre-reveive or update hooks)
change the global scripts in order to detect the Git repo they are executed in, and exit immediately (with status 0) if the repo matches one you don't want global hooks.
Related
For example, if the dev branch is behind the build branch when the two branches merge, the merge request can be created. But it is clear that it cannot merge because it is not possible to merge a backward branch into the current branch. In this case, I want to use the.gitlab-ci.yml configuration, To determine if the dev branch is behind the build branch, I wonder, can this be done? How to configure the.gitlab-ci.yml file if possible?
Basically, gitlab attempts the merge using git to determine if there's a conflict. It actually calls to gitaly to do this.
Basically the process goes like this:
The rails app in repository.rb will call to the gitaly conflict service to check for conclicts
The conflict service list_conflict_file in gitaly will call to git2go
The git2go conflicts subcommand will basically perform the git merge operation and return any conflicts that were encountered. This eventually makes its way back as a response to the call from rails in step (1)
So, if you wanted to do something similar in your CI/CD pipeline, you could use git (or a programatic API to git in your favorite language) to attempt a local merge of the two branches in order to detect conflicts.
My team uses Pre-commit in our repositories to run various code checks and formatters. Most of my teammates use it but some skip it entirely by committing with git commit --no-verify. Is there anyway to run something in CI/CD to ensure all Pre-commit hooks pass (we're using GitHub actions). If at least one hooks fails, then throw an error.
There are several choices:
an adhoc job which runs pre-commit run --all-files as demonstrated in pre-commit.com docs (you probably also want --show-diff-on-failure if you're using formatters)
pre-commit.ci a CI system specifically built for this purpose
pre-commit/action a github action which is in maintenance-only mode (not recommended for new usecases)
disclaimer: I created pre-commit, and pre-commit.ci, and the github action
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/
In my GIT based project, I need to set several environmental variables which is required by build scripts and many other ant targets.
For now I have a shell script which will export variables but each time a user opens a new bash window, he will need to repeat the steps by executing the shell script in order to set the environmental variables.
Most of these variables are user machine/env dependent and these are evaluated on the fly by shell before being exported.
If there a way to make it more dynamic. I understand that GIT provides hook and one possibility is that I can use hook to call the shell when user checkouts to a branch.
But here again GIT persists the current working branch and if user goes to a new bash window he would continue to be in previously chosen branch and he might not call git checkout branch, and which eventually will not call env variables shell.
So what is the best of handle this ?
I usually version a build wrapper script used by the user for launching the build (in the current or in a new shell window)
That way, the environment variables are always set at each build.
Furthermore, by versioning that build.sh/build.bat wrapper script, you keep the knowledge of which options/environment variable your project needs in order to be built.
That wrapper script, if changed, is versioned and can be audited (git blame): you know who changed what and when.
For my nodejs application, I am trying to run a hook through gitolite which performs the following actions (on the server side):
Update the repo to take into account the new changes (git fetch + git reset --hard newref)
Update the application dependencies (bower update, npm update / install)
Check some basic rules (coding rules, unit tests 100% ok, etc). Basically, it runs something like grunt test (jshint, mocha, ...)
Compile everything (grunt build)
Run the application
If one of these steps somehow fails, the whole process is stopped, the old application is restored and the push is denied.
My first approach was to add a pre-receive hook to this specific repo, but since it is triggered before the gitolite update hook (which checks about your rights), this was bad anyway.
So I now think about using VREFs which kind of work like a secondary update hook. So I'm pretty sure it would work like this, however it seems VREFs are usually here to perform only some basic checks, and don't intend to be used as something such a full deployment process.
I've done some research and it seems that usually people use a post-receive hook to deploy their app. This means that if something fails, the push is accepted anyway. I really would like to avoid accepting a commit which breaks the application at some point.
Is there a better way to achieve this deployment?