Feat/chain test - #13
Open
LowSwoo wants to merge 12 commits into
Open
Conversation
Change fixtures repository and defalt branch in fixtures
fix: fix MainConfig
Split the test source from the application source. TEST_REPOSITORY / TEST_BRANCH (git.fixtures.repository / git.fixtures.branch) keep selecting which fixtures and tests to use; a new APP_REPOSITORY / APP_PR group selects which version of the application to test. Without an explicit link the pipeline behaves exactly as before: the application repository is not cloned, nothing is built, no temporary image is created and the profile manifest image is used. A test pull request links itself to an application pull request declaratively in application-under-test.yml, or through CI inputs. CI then resolves the HEAD SHA of that pull request, reuses ghcr.io/<tests repo>/semaphore-ci:ci-pr-<number>-<sha> when it already exists and otherwise checks out, builds and pushes it. Changing only the tests never rebuilds the application; a new application commit yields a new image. Temporary images live in their own registry namespace, so release tags are never read or overwritten, and closed pull requests are cleaned up on a schedule. Application pull request updates reach the linked test pull requests through a repository_dispatch receiver; the link is always explicit and never inferred from branch names. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The registry stays the authority when the image is pushed, because the build and the test jobs run on different CI machines and a locally present image says nothing about what the test job can pull. With APP_BUILD_PUSH=false the image never leaves the machine, so the local image store is the authority and a rebuild is correctly skipped on the second run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
application-under-test.yml travels with the test pull request, so an uncommented
declaration reaches the default branch on merge. Left alone it would make main
build a long-closed application pull request forever, and every branch cut from
main would inherit the same stale link - exactly the regression the normal
scenario must not have.
Two independent guards close this:
* the declaration is only read for a test pull request. ci.yml passes
use_declaration_file only on pull_request events, so a push to main, a
scheduled run or a manual run without inputs always resolves to normal mode.
CI inputs keep working regardless.
* a closed or merged application pull request falls back to normal mode. Such a
pull request has no version left to test - its commits are either abandoned or
already on the application default branch - so pinning the tests to it would
be wrong. The reason is logged and shown in the run summary.
The run summary also reminds the author to comment the block out before merging
when the link came from the file.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…tion
The declaration file travelled with the test pull request and reached the default
branch on merge, so it needed two guards to stay harmless. The pull request
description has no such problem: it is not repository content, it never merges,
and nothing downstream can inherit it. It is now the single place a developer
declares the link, and application-under-test.yml is gone along with the
APP_LINK_FROM_FILE guard it required.
One trailer line in the test pull request description is the whole interface:
Application-PR: semaphoreui/semaphore#123
"#123", "123" and the full pull request URL are accepted equally, the key is case
insensitive, and text inside HTML comments is ignored so a pull request template
may carry a commented-out example. Two declarations are an error rather than a
silent pick, and the trailer must start a line so prose cannot trigger it.
APP_REPOSITORY / APP_PR stay as CI plumbing: the application pull request trigger
starts a run for a branch, where no pull request description is in context.
The fallback for a closed or merged application pull request stays, because a
test pull request can outlive the application pull request it was written for.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The application pull request is declared in the description, but the default pull_request event types are opened, synchronize and reopened - not edited. Adding the Application-PR line to an existing pull request therefore started nothing, and a manual re-run could not help either: it replays the original event payload, which still carries the description the pull request was opened with. Subscribing to edited makes the declared interface actually usable. The existing concurrency group cancels the superseded run, so an edit costs at most one restart. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Application PR: semaphoreui/semaphore#4195