Purpose of '.' in gitlab-ci.yml file

Hello, I am new to Gitlab and trying to understand existing gitlab-ci.yml files.

I have gone through below include section in the file, where i have noticed ‘.’ below the file name in file: “.poc-template-v4.yml”. What is that purpose of ‘.’ please help me know.

include:
  - project: "XXX/infrastructure/ci-templates"
    ref: "main"
    file: ".poc-template-v4.yml"
  - project: 'XXX/infrastructure/ci-templates'
    ref: "main"
    file: '.poc-node-ci-template.yml'

Thanks & Regards
Srivatsasa Janaswamy

Hi,

in your example, “.” is part of the file name. It’s a convention of prefixing config files with a “.” - those will be automatically hidden in linux. The gitlab CI config file is called .gitlab-ci.yml (including the “.” as first character of the name), and you have two yml files referenced, each starting with a “.” in the name, indicating they are config files and not the actual data.

Another example would be a git repository: There is a .git folder inside, which is the config of the local git repository.

Thanks @Metallkiller for the quick help. However i have seen similar ‘.’ for below snippets too.

`.dev_variables:
  variables: &dev_vars
    CHART_GCS_BUCKET_URL: $CHART_GCS_BUCKET_URL_DEV` 

.database-migration: &database-migration
  stage: before_deploy
  image: $FULL_IMAGE_NAME
  script:
    - cd /usr/src/app
   

database_migration is a job and actually a VARIABLES section is defined above .dev_variables. What does ‘.’ mean over here and what is meant by & in .database-migration: &database-migration, please help me know.

Thanks & Regards
Srivatsasa Janaswamy

Hey,

In this case “.” means jobs that don’t execute - normally it’s used for job templating.

Please have a look at my reply on a similar topic about syntax: Cannot find syntax meaning - #2 by paula.kokic

Super perfect. I was looking for Gitlab link you have added in your reply. Thanks @paula.kokic :slight_smile:

2 Likes

Strictly speaking, the ‘.’ is conventional for files that are meant to be hidden, not configuration files. Generally most configuration files I work with aren’t hidden, those that are tend to be the ‘dotfiles’ in my home directory. It’s nice when those files are hidden because when I run ls in my home folder, I don’t see dozens of those user configuration files muddying up my screen. Frequently when working with gitlab, I find it counterproductive that I can’t simply use ls to confirm that a CICD configuration file exists for a given repo.

I’m not sure how it became a convention in gitlab to hide important code files. In Jenkins, there eventually became a Jenkinsfile. I guess the way drone did it was where hiding the configuration files became a pattern, but there was an option to not hide the file (just writing it drone.yml). I preferred that because you’re right to ask, it seems like a bug to hide any of your code files.

You can configure a custom file name for looking up CI/CD configuration.

1 Like