moilanik
51922e2954
POST build status to Gitea REST API. Supports pending, success, failure, error states. Cross-repo reporting via optional root_commit and root_repo parameters. Includes mock Gitea API server shared between bats unit tests and cucumber acceptance tests.
73 lines
3.0 KiB
Gherkin
73 lines
3.0 KiB
Gherkin
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 @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 @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 @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 @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 @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
|
|
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
|