Merge branch 'initial' into 'develop'

    ref: 'master'

    file: '/templates/validation.yml'

  - project: 'to-be-continuous/bash'

    ref: '2.0.0'

    ref: '3.2'

    file: 'templates/gitlab-ci-bash.yml'

  - project: 'to-be-continuous/semantic-release'

    ref: '2.0.2'

    ref: '3.6'

    file: '/templates/gitlab-ci-semrel.yml'    

stages:

  - publish

variables:

  GITLAB_CI_FILES: "templates/gitlab-ci-xxx.yml"

  GITLAB_CI_FILES: "templates/gitlab-ci-gitlab-package.yml"

  BASH_SHELLCHECK_FILES: "*.sh"

semantic-release:

This includes bug reports, fixes, documentation, examples...

But first, read this page (including the small print at the end).

Contributions are available on https://gitlab.com/to-be-continuous/gitlab-package.

## Legal

All original contributions to _to be continuous_ are licensed under the

# GitLab CI template for XXX

# GitLab CI template for GitLab Package

This project implements a generic GitLab CI template for [XXX](https://link.to.tool.com/).

It provides several features, usable in different modes (by configuration).

This project implements a GitLab CI/CD template to publish artifacts to GitLab's [Generic Package Registry](https://docs.gitlab.com/ee/user/packages/generic_packages/).

## Usage

```yaml

include:

  - project: 'to-be-continuous/xxx'

  - project: 'to-be-continuous/gitlab-package'

    ref: '1.0.0'

    file: '/templates/gitlab-ci-xxx.yml'

    file: '/templates/gitlab-ci-gitlab-package.yml'

```

## Global configuration

The XXX template uses some global configuration used throughout all jobs.

The GitLab Package template uses some global configuration used throughout all jobs.

| Name                  | description                            | default value     |

| --------------------- | -------------------------------------- | ----------------- |

| `XXX_IMAGE`           | The Docker image used to run XXX       | `xxx:latest` |

| `GLPKG_IMAGE`         | The Docker image used to publish GitLab packages  | `registry.hub.docker.com/curlimages/curl:latest` |

## Jobs

### `xxx-build` job

This job performs **build and tests** at once.

It uses the following variable:

| Name                  | description                              | default value     |

| --------------------- | ---------------------------------------- | ----------------- |

| `XXX_BUILD_ARGS`      | Arguments used by the build job          | `build --with-default-args` |

### SonarQube analysis

If you're using the SonarQube template to analyse your XXX code, here are 2 sample `sonar-project.properties` files.

### `packages-publish` job

```properties

# see: https://docs.sonarqube.org/latest/analysis/languages/xxx/

# set your source directory(ies) here (relative to the sonar-project.properties file)

sonar.sources=.

# exclude unwanted directories and files from being analysed

sonar.exclusions=output/**,**/*_test.xxx

This job **publishes** files to [GitLab Generic Package](https://docs.gitlab.com/ee/user/packages/generic_packages/).

# set your tests directory(ies) here (relative to the sonar-project.properties file)

sonar.tests=.

sonar.test.inclusions=**/*_test.xxx

# tests report (TODO)

sonar.xxx.testExecutionReportPaths=reports/sonar_test_report.xml

# coverage report (TODO)

sonar.xxx.coverage.reportPaths=reports/coverage.cov

```

More info:

* [XXX language support](https://docs.sonarqube.org/latest/analysis/languages/xxx/)

* [test coverage & execution parameters](https://docs.sonarqube.org/latest/analysis/coverage/)

* [third-party issues](https://docs.sonarqube.org/latest/analysis/external-issues/)

### `xxx-lint` job

This job performs a [lint](link-to-the-tool) analysis of your code, mapped to the `build` stage.

This job is bound to the `publish` stage and is executed on a Git tag with a semantic version pattern (`v?[0-9]+\.[0-9]+\.[0-9]+`, _configurable_).

It uses the following variables:

| Name                  | description                              | default value     |

| --------------------- | ------------------------------------------ | ----------------- |

| `XXX_LINT_IMAGE`      | The Docker image used to run the lint tool | `xxx-lint:latest` |

| `XXX_LINT_DISABLED`   | Set to `true` to disable the `lint` analysis| _none_ (enabled) |

| `XXX_LINT_ARGS`       | Lint [options and arguments](link-to-the-cli-options) | `--serevity=medium` |

### `xxx-depcheck` job

This job enables a manual [dependency check](link-to-the-tool) analysis of your code, mapped to the `test` stage.

It uses the following variables:

| Name                  | description                                | default value     |

| --------------------- | ------------------------------------------ | ----------------- |

| `XXX_DEPCHECK_IMAGE`  | The Docker image used to run the dependency check tool | `xxx-depcheck:latest` |

| `XXX_DEPCHECK_ARGS`   | Dependency check [options and arguments](link-to-the-cli-options) | _none_ |

### `xxx-publish` job

This job is **disabled by default** and performs a publish of your built binaries.

It uses the following variables:

| Name                  | description                            | default value     |

| --------------------- | -------------------------------------- | ----------------- |

| `XXX_PUBLISH_ENABLED` | Variable to enable the publish job     | _none_ (disabled) |

| `XXX_PUBLISH_ARGS`    | Arguments used by the publish job      | `publish --with-default-args` |

| :lock: `XXX_PUBLISH_LOGIN` | Login to use to publish           | **has to be defined** |

| :lock: `XXX_PUBLISH_PASSWORD` | Password to use to publish     | **has to be defined** |

### Secrets management

Here are some advices about your **secrets** (variables marked with a :lock:):

1. Manage them as [project or group CI/CD variables](https://docs.gitlab.com/ee/ci/variables/#create-a-custom-variable-in-the-ui):

    * [**masked**](https://docs.gitlab.com/ee/ci/variables/#mask-a-custom-variable) to prevent them from being inadvertently

      displayed in your job logs,

    * [**protected**](https://docs.gitlab.com/ee/ci/variables/#protect-a-custom-variable) if you want to secure some secrets

      you don't want everyone in the project to have access to (for instance production secrets).

2. In case a secret contains [characters that prevent it from being masked](https://docs.gitlab.com/ee/ci/variables/#masked-variable-requirements), 

  simply define its value as the [Base64](https://en.wikipedia.org/wiki/Base64) encoded value prefixed with `@b64@`:

  it will then be possible to mask it and the template will automatically decode it prior to using it.

3. Don't forget to escape special characters (ex: `$` -> `$$`).

| --------------------- | ---------------------------------------- | ----------------- |

| `GLPKG_FILES`         | Glob patterns matching files to include in the GitLab package (:warning: does not support double star). | _none_ (mandatory) |

| `GLPKG_PACKAGE`       | Name of the package to publish           | `$CI_PROJECT_NAME` |

# Security Policy

## Supported Versions

Security fixes and updates are only applied to the latest released version. So always try to be up to date.

## Reporting a Vulnerability

In order to minimize risks of attack while investigating and fixing the issue, any vulnerability shall be reported by 

opening a [**confidential** issue on gitlab.com](https://gitlab.com/to-be-continuous/gitlab-package/-/issues/new?issue[confidential]=true&issue[description]=%28type+in+the+vulnerability+details+here%29%0A%0A%2Flabel%20~%22kind%3A%3Avulnerability%22).

Follow-up and fixing will be made on a _best effort_ basis.

If you have doubts about a potential vulnerability, please reach out one of the maintainers on Discord.

files:

    template: ./templates/gitlab-ci-gitlab-package.yml

    documentation: ./README.md

    changelog: ./CHANGELOG.md

data:

    description: "Publish artifacts to GitLab's Generic Package Registry"

    public: true

    labels:

    - to be continuous

    - GitLab Package Registry

    - Build

    license: LGPL v3

    deprecated: false

 No newline at end of file