# GitLab CI

**This guide assumes you have a working website project on your machine integrated with DatoCMS**

If that's not your case, you can head over to the [main documentation](https://www.datocms.com/docs/general-concepts.md) to see how to properly configure the DatoCMS administrative area and how to integrate DatoCMS with your favorite framework.

### Create your Git repository

DatoCMS supports both GitLab.com and self-managed GitLab instances. The first thing to do is to initialize a new Git repository in your website's local directory:

Terminal window

```bash
$ git init
$ git add .
```

Commit the files that you've staged in your local repository.

Terminal window

```bash
$ git commit -m 'First commit'
```

Now create a new repository on [GitLab](https://gitlab.com/projects/new). Once done, copy the remote repository URL. In Terminal, add the URL for the remote repository where your local repository will be pushed.

Terminal window

```bash
$ git remote add origin YOUR_GITLAB_REPOSITORY_URL
```

Now, it's time to push the changes in your local repository to GitLab.

Terminal window

```bash
git push -u origin main
```

Now that your project is up and running on GitLab, let's configure a GitLab Pipeline that will publish your website on S3 after each further Git push.

### Enable GitLab Pipeline

GitLab offers a continuous integration service out of the box. If you add a `.gitlab-ci.yml` file to the root directory of your repository, then each commit or push triggers your CI pipeline.

### Add the DatoCMS API token as environment variable

Go to the *Settings \> CI/CD* page of your GitLab project, and in the *Variables* section, add an environment variable called `DATO_API_TOKEN` containing the read-only API token of your DatoCMS administrative area:

(Image content)

You can find the API token in the *Settings \> API tokens* section of your DatoCMS project:

(Image content)

### Configure .gitlab-ci.yml

The `.gitlab-ci.yml` file tells the GitLab runner what to do. By default it runs a pipeline with three stages: build, test, and deploy. You don't need to use all three stages; stages with no jobs are simply ignored.

Please refer to the official GitLab documentation to learn everything regarding [how to configure your build](https://gitlab.com/help/ci/quick_start/README).

#### Jekyll

Here is an example `.gitlab-ci.yml` that you can use to run your build using Jekyll:

```yaml


# requiring the environment of Ruby 2.3.x
image: ruby:2.3

# add cache to 'vendor' for speeding up builds
cache:
  paths:
    - vendor/

before_script:
  - pip install awscli
  - bundle install --path vendor

variables:
  S3_BUCKET_NAME: "yourbucket"

# add a job called 'deploy'
deploy:
  script:
    # first dump all the remote content as local files
    - bundle exec dato dump
    # then generate the website
    - bundle exec dato jekyll build
    # copy the /public folder to S3 bucket
    - aws s3 cp ./ s3://$S3_BUCKET_NAME/ --recursive --exclude "*" --include "*.html"
  only:
    - main # the 'deploy' job will affect only the 'main' branch
```

## Related content in "Hosting & Deployment"

- [Hosting and CI Building Solutions](https://www.datocms.com/docs/hosting-and-deployment.md)
- [Netlify](https://www.datocms.com/docs/hosting-and-deployment/netlify.md)
- [Vercel](https://www.datocms.com/docs/hosting-and-deployment/vercel.md)
- [GitLab CI](https://www.datocms.com/docs/hosting-and-deployment/gitlab.md)
- [Custom webhook](https://www.datocms.com/docs/hosting-and-deployment/custom-webhook.md)