-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Query and use the repository.branch when defined in spec #393
Conversation
ba6712c
to
e0fdeda
Compare
Thanks for tackling this! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I appreciate the naming symmetry with types and fields in the backend where possible!
type Branch struct { | ||
Name string | ||
Target struct{ OID string } | ||
Target Target |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hit Control-Enter too early, but the one thing that we do need is a changelog! |
993733d
to
e74598e
Compare
* Query and use the repository.branch when defined in spec * Remove debug pritning * Query specific commit and not query branches * Merge two repository queries * Fix critical indentation error (and unused type) * Fix wrong query * Add changelog entry
This fixes https://github.com/sourcegraph/sourcegraph/issues/15070 by changing the evaluation of the
on.repository
field in the campaign spec to actually query for and use thebranch
attribute.It queries the GraphQL API for a commit that matches the exact rev and returns an error if no commit was found.
If the campaign spec uses
repositoriesMatchingQuery
andrepository
, like thisthen the second branch,
thorstens-test-branch
, is checked out and used as the base branch for the changeset.What we don't support yet is using a revspec in the search query, like
repo:github.com/sourcegraph/automation-testing@thorstens-test-branch foobar
, and using that to check out the branch. We can tackle that in a separate ticket/PR.For now, this fixes the original problem and allows users to run the steps for a specified subset of repositories in specific branches.
(Side note: the search results in the template variable
${{ repository.search_result_paths }}
are populated by the query, even though they might not match any results in the second branch — that's undefined behaviour for now, but I want to document it in the docs.)