Commit Graph

18 Commits

Author SHA1 Message Date
Zeger-Jan van de Weg c2cdefd441
Force push is handled by Gitaly now
Closes gitlab-org/gitaly#348
2018-06-19 15:35:17 +02:00
Rubén Dávila c5d4f10b80 Pass the --in-commit-order arg to `git-rev-list`
@jamedjo has found a good improvement in the performance of the LFS
integrity check by passing this arg
2018-06-07 12:09:45 -05:00
Francisco Javier López 86d39016a2
Moving rev-list lfs options to Lfschanges 2018-06-06 21:55:32 +02:00
Francisco Javier López e8f49b4bee Support LFS objects when creating a project by import 2018-06-06 16:42:18 +00:00
Alejandro Rodríguez 98affa75ed Refactor Gitlab::Git code related to LFS changes for Gitaly migration
We stop relying on Gitlab::Git::Env for the RevList class, and use
Gitlab::Git::Repository#run_git methods inteaad. The refactor also fixes
another issue, since we now top using "path_to_repo" (which is a
Repository model method).
2018-02-02 16:27:01 -03:00
James Edwards-Jones c4dd7b8296 Prevent RevList failing on non utf8 paths 2018-01-16 13:27:59 +00:00
James Edwards-Jones ca049902dc Gitlab::Git::RevList and LfsChanges use lazy popen 2017-11-06 10:20:14 +00:00
James Edwards-Jones fb3f9c6e50 Detect changes to LFS pointers for pruning and integrity check
Gitlab::Git::Blob.batch_lfs_metadata can be used to check for LFS pointers. It uses a lazy enumorator and filters by blob size
2017-11-01 16:41:05 +00:00
Jacob Vosmaer e73af42239 Add Gitlab::Git::Env.to_env_hash 2017-10-16 13:19:44 +02:00
Jacob Vosmaer f6966d8922 Include RevList error messages in exceptions 2017-10-03 16:33:32 +02:00
Alejandro Rodríguez 34eeac6108 Use Gitlab::Git's Popen on that module's code
This allows the current Gitaly migration to depend on less code outside
of the Gitlab::Git module
2017-09-20 13:21:54 +02:00
Jacob Vosmaer 47c844bf34 Add Gitaly notes and annotations to Gitlab::Git 2017-07-12 17:06:31 +02:00
Rémy Coutable ae88355bb8 Retrieve Git-specific env in Gitlab::Git::RevList and add a new #new_refs method
Signed-off-by: Rémy Coutable <remy@rymai.me>
2017-04-10 16:10:18 +02:00
Rémy Coutable 212967aefb
Reject blank environment vcariables in Gitlab::Git::RevList
Signed-off-by: Rémy Coutable <remy@rymai.me>
2016-12-20 09:45:37 +01:00
Timothy Andrew e394d2872a Implement final review comments from @rymai.
- `raise "string"` raises a `RuntimeError` - no need to be explicit
- Remove top-level comment in the `RevList` class
- Use `%w()` instead of `%w[]`
- Extract an `environment_variables` method to cache `env.slice(*ALLOWED_VARIABLES)`
- Use `start_with?` for env variable validation instead of regex match
- Validation specs for each allowed environment variable were identical. Build them dynamically.
- Minor change to `popen3` expectation.
2016-12-16 23:32:25 +05:30
Timothy Andrew 3e1442766f Implement review comments from @dbalexandre.
- Don't define "allowed environment variables" in two places.
- Dispatch to different arities of `Popen.open` without an if/else block.
- Use `described_class` instead of explicitly stating the class name within a
- spec.
- Remove `git_environment_variables_validator_spec` and keep the validation inline.
2016-12-16 23:32:25 +05:30
Timothy Andrew a2b39feb1a Validate environment variables in `Gitlab::Git::RevList`
The list of environment variables in `Gitlab::Git::RevList` need to be validate
to make sure that they don't reference any other project on disk.

This commit mixes in `ActiveModel::Validations` into `Gitlab::Git::RevList`, and
validates that the environment variables are on the level (using a custom
validator class). If the validations fail, the force push is still executed
without any environment variables set.

Add specs for the validation using shared examples.
2016-12-16 23:32:25 +05:30
Timothy Andrew f82d549d26 Accept environment variables from the `pre-receive` script.
1. Starting version 2.11, git changed the way the pre-receive flow works.

  - Previously, the new potential objects would be added to the main repo. If the
    pre-receive passes, the new objects stay in the repo but are linked up. If
    the pre-receive fails, the new objects stay orphaned in the repo, and are
    cleaned up during the next `git gc`.

  - In 2.11, the new potential objects are added to a temporary "alternate object
    directory", that git creates for this purpose. If the pre-receive passes, the
    objects from the alternate object directory are migrated to the main repo. If
    the pre-receive fails the alternate object directory is simply deleted.

2. In our workflow, the pre-recieve script (in `gitlab-shell) calls the
   `/allowed` endpoint, which calls out directly to git to perform
   various checks. These direct calls to git do _not_ have the necessary
   environment variables set which allow access to the "alternate object
   directory" (explained above). Therefore these calls to git are not able to
   access any of the new potential objects to be added during this push.

3. We fix this by accepting the relevant environment variables
   (GIT_ALTERNATE_OBJECT_DIRECTORIES, GIT_OBJECT_DIRECTORY) on the
   `/allowed` endpoint, and then include these environment variables while
   calling out to git.

4. This commit includes (whitelisted) these environment variables while making
   the "force push" check. A `Gitlab::Git::RevList` module is extracted to
   prevent `ForcePush` from being littered with these checks.
2016-12-16 23:32:25 +05:30