71 lines
3.1 KiB
Gherkin
71 lines
3.1 KiB
Gherkin
Feature: CI pipeline
|
|
As a developer
|
|
I want automated CI pipelines for feature and master branches
|
|
So that every commit is tested and master builds produce deployable artifacts
|
|
|
|
# ---------------------------------------------------------------------------
|
|
# Ticket 0006: ci-feature.yml — Feature branch CI workflow
|
|
# ---------------------------------------------------------------------------
|
|
|
|
Background:
|
|
Given the project has a CI configuration file in its repository
|
|
|
|
@ticket-0006 @mock @wip @real
|
|
Scenario: Feature branch runs unit tests and publishes reports
|
|
When a commit is pushed to a feature branch
|
|
Then the unit tests are executed
|
|
And the test reports are published
|
|
And each step reports its status to the commit
|
|
|
|
@ticket-0006 @mock @wip @real
|
|
Scenario: Feature branch reports failure when tests do not pass
|
|
When tests fail on a feature branch
|
|
Then the commit shows a failure status with a link to the test results
|
|
|
|
@ticket-0006 @mock @wip @real
|
|
Scenario: Feature branch does not build a container image
|
|
Given a commit is pushed to a feature branch
|
|
When the CI pipeline runs
|
|
Then no container image is built or pushed
|
|
|
|
@ticket-0006 @mock @wip
|
|
Scenario: Only one pipeline runs at a time for the same feature branch
|
|
When a new commit is pushed to a feature branch while a pipeline is already running
|
|
Then the existing pipeline continues and the new one waits
|
|
|
|
# ---------------------------------------------------------------------------
|
|
# Ticket 0009: ci-master.yml — Master branch CI workflow
|
|
# ---------------------------------------------------------------------------
|
|
|
|
@ticket-0009 @mock @wip @real
|
|
Scenario: Master branch builds and pushes a container image
|
|
When a commit is pushed to the master branch
|
|
Then the container image is built with version labels
|
|
And the image is pushed to the container registry
|
|
And the commit is tagged with the build version
|
|
|
|
@ticket-0009 @mock @wip @real
|
|
Scenario: Master branch skips container build if already built
|
|
When a commit on the master branch is already tagged with a build version
|
|
And a new pipeline is triggered for the same commit
|
|
Then the container build is skipped
|
|
And the pipeline proceeds to reporting and test flow
|
|
|
|
@ticket-0009 @mock @wip @real
|
|
Scenario: Master branch runs the full test flow chain after a successful build
|
|
When the container build and push succeed on the master branch
|
|
Then the deployment to the first environment is dispatched
|
|
And after deployment succeeds the integration tests are dispatched
|
|
And the end-to-end tests run as the final step in the chain
|
|
|
|
@ticket-0009 @mock @wip @real
|
|
Scenario: Master branch stops the test flow chain when a step fails
|
|
When a step in the test flow chain fails
|
|
Then the remaining steps are not executed
|
|
And the commit shows a failure status pointing to the failed step
|
|
|
|
@ticket-0009 @mock @wip
|
|
Scenario: Only one master pipeline runs at a time for the same project
|
|
When a new commit is pushed to master while a pipeline is already running
|
|
Then the existing pipeline continues and the new one waits
|