tiketit ja featuret vaihe 1
This commit is contained in:
moilanik
@@ -0,0 +1,70 @@
|
||||
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
|
||||
@@ -0,0 +1,72 @@
|
||||
Feature: Commit status visibility
|
||||
As a developer
|
||||
I want to see build and deployment statuses on commits
|
||||
So that I know the state of each commit at a glance
|
||||
|
||||
Background:
|
||||
Given a project repository exists in Gitea
|
||||
And a commit has been pushed to the repository
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Ticket 0001: report-status.sh — Build status reporting to commits
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
@ticket-0001 @mock @wip @real
|
||||
Scenario: Build step reports pending status to commit
|
||||
When a build step starts executing
|
||||
Then the commit shows a pending status with a description of the step
|
||||
|
||||
@ticket-0001 @mock @wip @real
|
||||
Scenario: Build step reports successful completion with a result link
|
||||
When a build step completes successfully and reports its results
|
||||
Then the commit shows a success status with a clickable link to the results
|
||||
|
||||
@ticket-0001 @mock @wip @real
|
||||
Scenario: Build step reports failure when tests do not pass
|
||||
When a build step fails
|
||||
Then the commit shows a failure status with a description of what went wrong
|
||||
|
||||
@ticket-0001 @mock @wip @real
|
||||
Scenario: Multiple build steps report distinct statuses on the same commit
|
||||
When several build steps each report their own status to the same commit
|
||||
Then each status appears under a unique label on the commit
|
||||
|
||||
@ticket-0001 @mock @wip @real
|
||||
Scenario: Deployment step reports status back to the source commit
|
||||
When a deployment finishes for a commit that originated from another repository
|
||||
Then the source commit shows the deployment status alongside the build status
|
||||
|
||||
@ticket-0001 @mock @wip
|
||||
Scenario: Status reporting is interrupted when the build system cannot be reached
|
||||
When a build step tries to report status but the build system is unavailable
|
||||
Then the pipeline fails with a clear error message
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Ticket 0004: tag-commit.sh — Version tagging on commits
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
@ticket-0004 @mock @wip @real
|
||||
Scenario: Build tags a commit with a version number after a successful docker push
|
||||
When a container image is built and pushed successfully
|
||||
Then the commit receives a version tag that includes the build number
|
||||
|
||||
@ticket-0004 @mock @wip @real
|
||||
Scenario Outline: Tagging a commit with a specific version
|
||||
When a build completes with version "<version>"
|
||||
Then the commit is tagged with "<version>"
|
||||
|
||||
Examples:
|
||||
| version |
|
||||
| 1.2.3.42 |
|
||||
| 2.0.0.1 |
|
||||
| 0.1.0.15 |
|
||||
|
||||
@ticket-0004 @mock @wip
|
||||
Scenario: Tagging fails when the same version tag already exists on the commit
|
||||
When a build tries to tag a commit with a version that is already tagged
|
||||
Then the tagging fails with a notification that the tag already exists
|
||||
|
||||
@ticket-0004 @mock @wip
|
||||
Scenario: Tagging fails when no version is provided
|
||||
When a build tries to tag a commit without specifying a version
|
||||
Then the tagging fails with an error
|
||||
@@ -0,0 +1,45 @@
|
||||
Feature: Deployment
|
||||
As a developer
|
||||
I want automated GitOps deployments to environments
|
||||
So that container versions are deployed consistently and the chain is traceable
|
||||
|
||||
Background:
|
||||
Given a container image has been built and pushed
|
||||
And a Helm configuration repository exists
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Ticket 0007: deploy.yml — GitOps deployment workflow
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
@ticket-0007 @mock @wip @real
|
||||
Scenario: Deploy a container version to a staging environment
|
||||
When a deployment is dispatched to the staging environment with a new version
|
||||
Then the Helm configuration is updated with the new container version
|
||||
And the change is committed and pushed to the configuration repository
|
||||
|
||||
@ticket-0007 @mock @wip @real
|
||||
Scenario: Deploy a container version to the production environment
|
||||
When a deployment is dispatched to the production environment with a new version
|
||||
Then the Helm configuration is updated with the new container version
|
||||
And the change is committed and pushed to the configuration repository
|
||||
|
||||
@ticket-0007 @mock @wip @real
|
||||
Scenario: Deployment reports its source back to the originating commit
|
||||
When a deployment completes successfully
|
||||
Then the originating commit shows a deployed status with a link to the deployment commit
|
||||
|
||||
@ticket-0007 @mock @wip @real
|
||||
Scenario: Deployment configuration commit shows where the deploy came from
|
||||
When a deployment commit is created in the configuration repository
|
||||
Then the configuration commit shows a trace status linking back to the source commit
|
||||
|
||||
@ticket-0007 @mock @wip @real
|
||||
Scenario: Developer navigates from source commit to deployment commit and back
|
||||
When a developer views the source commit
|
||||
Then they can click a deploy status to navigate to the deployment commit
|
||||
And from the deployment commit they can navigate back to the source commit
|
||||
|
||||
@ticket-0007 @mock @wip
|
||||
Scenario: Only one deployment runs at a time for the same environment
|
||||
When a new deployment is dispatched to an environment that already has one in progress
|
||||
Then the existing deployment continues and the new one waits
|
||||
@@ -0,0 +1,76 @@
|
||||
Feature: Report browsing
|
||||
As a developer
|
||||
I want to browse test reports and build history in a web browser
|
||||
So that I can review test results, compare builds, and navigate between reports
|
||||
|
||||
Background:
|
||||
Given a project has completed at least one build
|
||||
And the build reports are accessible through the report storage
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Ticket 0003: push-reports.sh — Pushing test reports to storage
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
@ticket-0003 @mock @wip @real
|
||||
Scenario: Push Cucumber test report after a successful test run
|
||||
When a test run produces a Cucumber report
|
||||
Then the report is stored and accessible at a permanent web address
|
||||
|
||||
@ticket-0003 @mock @wip @real
|
||||
Scenario: Push code coverage report after analysis
|
||||
When a build generates a code coverage report
|
||||
Then the coverage report is stored and accessible at a permanent web address
|
||||
|
||||
@ticket-0003 @mock @wip @real
|
||||
Scenario Outline: Push different types of test artifacts
|
||||
When a build produces a "<report_type>" report
|
||||
Then the report is stored under its own section in the build's report listing
|
||||
|
||||
Examples:
|
||||
| report_type |
|
||||
| Cucumber |
|
||||
| JaCoCo |
|
||||
| JUnit |
|
||||
| Maven Site |
|
||||
|
||||
@ticket-0003 @mock @wip @real
|
||||
Scenario: Report push updates the build report index
|
||||
When a report is pushed to storage
|
||||
Then the build's report listing includes a link to the new report with its display name
|
||||
|
||||
@ticket-0003 @mock @wip
|
||||
Scenario: Report push fails when the source report directory does not exist
|
||||
When a build tries to push a report but the report directory is missing
|
||||
Then the pipeline fails with a clear error
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Ticket 0005: report-service/ — HTML index generation for report browsing
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
@ticket-0005 @mock @wip @real
|
||||
Scenario: Developer sees a list of all builds for a project
|
||||
When a developer opens the project build history page
|
||||
Then all builds are listed in chronological order with the newest first
|
||||
And each build shows its short commit identifier, date, branch, and status
|
||||
|
||||
@ticket-0005 @mock @wip @real
|
||||
Scenario: Developer navigates into a specific build to see its reports
|
||||
When a developer clicks on a build in the project build history
|
||||
Then a page opens showing all reports available for that build as clickable links
|
||||
|
||||
@ticket-0005 @mock @wip @real
|
||||
Scenario: Build listing shows success or failure status with a clear indicator
|
||||
When a build has completed
|
||||
Then the build listing shows a success indicator for passing builds
|
||||
And a failure indicator for failing builds
|
||||
|
||||
@ticket-0005 @mock @wip @real
|
||||
Scenario: Developer can navigate back from a build report listing to the project build history
|
||||
When a developer is viewing the reports of a specific build
|
||||
Then a navigation link leads back to the project build history page
|
||||
|
||||
@ticket-0005 @mock @wip @real
|
||||
Scenario: Developer opens two builds side by side to compare reports
|
||||
When a developer views two different builds in separate browser tabs
|
||||
Then both builds show their respective report listings
|
||||
And the developer can compare which tests passed or failed between the builds
|
||||
@@ -0,0 +1,92 @@
|
||||
Feature: Test execution
|
||||
As a test engineer
|
||||
I want integration and end-to-end tests to run automatically after deployment
|
||||
So that I can verify the deployed version works correctly
|
||||
|
||||
Background:
|
||||
Given a deployment has completed in the target environment
|
||||
And the test project repository exists with test definitions
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Ticket 0002: dispatch-workflow.sh — Dispatching and polling workflows
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
@ticket-0002 @mock @wip @real
|
||||
Scenario: Dispatch a test workflow and wait for its completion
|
||||
When a test workflow is dispatched to a test project
|
||||
Then the pipeline waits until the test workflow finishes
|
||||
And the pipeline continues only after receiving a success result
|
||||
|
||||
@ticket-0002 @mock @wip @real
|
||||
Scenario: Dispatch fails when the dispatched test workflow fails
|
||||
When a test workflow is dispatched and the tests fail
|
||||
Then the calling pipeline reports failure
|
||||
|
||||
@ticket-0002 @mock @wip
|
||||
Scenario: Dispatch times out when the test workflow takes too long
|
||||
When a test workflow is dispatched but does not finish within the allowed time
|
||||
Then the calling pipeline reports a timeout error
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Ticket 0011: check-version.sh — Version polling with Fibonacci backoff
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
@ticket-0011 @mock @wip @real
|
||||
Scenario: Target version is eventually found after a few retries
|
||||
When the deployed version in the environment does not match the expected version initially
|
||||
And the version check is retried with increasing wait times
|
||||
Then the version eventually matches and the test flow proceeds
|
||||
|
||||
@ticket-0011 @mock @wip
|
||||
Scenario: Target version is never found within the maximum retries
|
||||
When the deployed version keeps returning a different version than expected
|
||||
And the maximum number of retries is reached
|
||||
Then the version check fails with a version mismatch error
|
||||
|
||||
@ticket-0011 @mock @wip
|
||||
Scenario: Version check fails when the version endpoint cannot be reached
|
||||
When the version API endpoint is not responding
|
||||
Then the version check fails with an error
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Ticket 0008: test.yml — Test flow execution and cross-repo reporting
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
@ticket-0008 @mock @wip @real
|
||||
Scenario: Test flow verifies the deployed version before running tests
|
||||
When a test flow is triggered
|
||||
Then the version of the running container is checked against the expected version
|
||||
And tests proceed only after the version matches
|
||||
|
||||
@ticket-0008 @mock @wip @real
|
||||
Scenario: Test flow executes tests and publishes reports
|
||||
When tests are executed as part of the test flow
|
||||
Then the test reports are published to the report storage
|
||||
And the reports are accessible through the browse interface
|
||||
|
||||
@ticket-0008 @mock @wip @real
|
||||
Scenario: Test flow reports results to the test project commit
|
||||
When tests complete
|
||||
Then the test project commit shows a test status with a link to the report
|
||||
|
||||
@ticket-0008 @mock @wip @real
|
||||
Scenario: Test flow reports results back to the source commit
|
||||
When tests complete for a source commit
|
||||
Then the source commit shows which tests were run and a link to the results
|
||||
|
||||
@ticket-0008 @mock @wip @real
|
||||
Scenario: Test flow reports the tested version on the deployment commit
|
||||
When tests complete
|
||||
Then the deployment commit shows which version was tested and a link to the test results
|
||||
|
||||
@ticket-0008 @mock @wip @real
|
||||
Scenario: Developer traces the full chain from source commit through deployment to test results
|
||||
When a developer views the source commit
|
||||
Then they can follow the deployment status to the deployment commit
|
||||
And from the deployment commit they can follow the test status to the test results
|
||||
And from the test results they can navigate back to the source commit
|
||||
|
||||
@ticket-0008 @mock @wip @real
|
||||
Scenario: Developer sees which container version was tested on the test project commit
|
||||
When a developer views the test project commit
|
||||
Then the commit shows the tested container version and the source commit it originated from
|
||||
Reference in New Issue
Block a user