Какой смысл `cache: key` в .gitlab-ci.yml? - PullRequest
Новая
       20

Какой смысл `cache: key` в .gitlab-ci.yml?

2 голосов
/ 31 марта 2020

В соответствии с документацией:

Поскольку кеш распределяется между заданиями, если вы используете разные пути для разных заданий, вам также следует установить другой кеш: ключ, иначе содержимое кеша может быть перезаписано.

Это звучит странно для меня.

Так что, если я "использую разные пути для разных заданий", как это 

job_a:
  paths:
    - binaries/

job_b:
  paths:
    - node_modules/

Как мог кэш будет перезаписан ..?

Означает ли это, что node_modules будет перезаписывать binaries ?? потому что ключ кеша такой же?

Кто-нибудь знает подробности реализации кеша в gitlab?

Работает ли он так ?? 1020 * 


$job_cache_key = $job_cache_key || 'default';

if ($cache[$job_cache_key]){
    return $cache[$job_cache_key];
}

$cache[$job_cache_key] = $job_cache;

return $job_cache;

1 Ответ

0 голосов
/ 31 марта 2020

Ключи кэширования в GitLab mimick Кэширование Rails , хотя, как указано app/models/concerns/faster_cache_keys.rb: 

  # Rails' default "cache_key" method uses all kind of complex logic to figure
  # out the cache key. In many cases this complexity and overhead may not be
  # needed.
  #
  # This method does not do any timestamp parsing as this process is quite
  # expensive and not needed when generating cache keys. This method also relies
  # on the table name instead of the cache namespace name as the latter uses
  # complex logic to generate the exact same value (as when using the table
  # name) in 99% of the cases.

Сам конвейер начинается с инициализации своего локального кэша: lib/gitlab/ci/pipeline/seed/build/cache.rb

Пример кэша можно увидеть в spec/lib/gitlab/ci/pipeline/seed/build/cache_spec.rb

Означает ли это, что node_modules будет перезаписывать binaries ?? потому что ключ кеша такой же?

Нет: Каждое задание будет использовать свой собственный набор путей, который переопределяет любой набор путей, определенный в глобальном кеше.

gitlab-org/gitlab-runner Issue 2838 спрашивает о кеше для каждого задания и приводит пример: 

stages:
- build
- build-image

# the following line is the global cache configuration but also defines an anchor with the name of "cache"
# you can refer to the anchor and reuse this cache configuration in your jobs.
# you can also add and replace properties
# In the job definitions you will find examples.
# for more information regarding reuse in YAML files, see https://blog.daemonl.com/2016/02/yaml.html
cache: &cache
    paths:
    - api/node_modules/
    - global/node_modules/
    - frontend/node_modules/

# first job, it does not have an explicit cache definition:
# therefore it uses the global cache definition!
build-app:
    stage: build
    image: node:8
    before_script:
    - yarn
    - cd frontend
    script:
    - npm run build

# a job in a later stage, have a look at the cache block!
# it "inherits" from the global cache block and adds the "policy: pull" key / value
build-image-api:
    stage: build-image
    image: docker
    dependencies: []
    cache:
        <<: *cache
        policy: pull
    before_script:
    # .... and so on

Этот механизм наследования также задокументирован в " Inherit global config, но переопределяет спецификацию c настройки для задания"раздел кэширования

Вы можете переопределить настройки кеша без перезаписи глобального кеша с помощью якорей.
Например, если вы хотите переопределить политику для одного задания : 

cache: &global_cache
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
      - public/
      - vendor/
    policy: pull-push

job:
  cache:
    # inherit all global cache settings
    <<: *global_cache
    # override the policy
    policy: pull
...