CI setup in our Gerrit instance

Each new patchset submitted to Gerrit for review will trigger a continuous integration check:

• Jenkins pipeline defined in .ci/Jenkinsfile will be executed on our Jenkins instance. Missing .ci/Jenkinsfile will cause this check to fail.
• Commit message format will be validated using dco-go. Submit pull requests to dco-go if you need to modify validation logic.

Failure of any of these checks will prevent the change from being merged. Gerrit administrators can override CI automation votes but should resort to this only in disaster recovery scenarios.

Retrigger CI jobs in Jenkins

If you need to rerun some previously executed CI job for a Gerrit patchset you must use 'Retrigger' button in Jenkins UI. Using 'Rebuild' or 'Replay' will re-execute the job but will not submit the resulting vote to the relevant Gerrit review thread.

You should not need to retrigger CI jobs during normal operation. If some CI checks are flaky report an issue to the project repository. If CI check crashed due to an infrastructure problem - report an issue to frostfs-infra.

Using [skip ci] tag in commit message

If you wish to avoid triggering CI pipeline for a specific Gerrit changeset you may add [skip ci] to commit message header. This will disable .ci/Jenkinsfile execution for the current commit.

Setting [skip ci] will make the change unmergeable because of the missing 'Verified +1' vote. Use this only if you wish to try some new (to you) Gerrit functionality while avoiding unnecessary load on CI infrastructure. If you will eventually need to merge this patchset, remove [skip ci] tag from the commit message and wait for CI checks to pass.

This feature is intended to be used only for playground purposes. Merging changes that bypass CI checks is intentionally not implemented.