tiketit ja featuret vaihe 1
This commit is contained in:
@@ -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
|
||||
Reference in New Issue
Block a user