-
Notifications
You must be signed in to change notification settings - Fork 9
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
feat: flag to pull request create that allows update of existing PR #20
feat: flag to pull request create that allows update of existing PR #20
Conversation
Hi @waciumawanjohi. Thanks for your PR. I'm waiting for a jenkins-x-plugins or todo member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. |
/assign @rawlingsj |
/retest |
@waciumawanjohi: Cannot trigger testing until a trusted user reviews the PR and leaves an In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. |
@@ -75,6 +87,8 @@ func NewCmdCreatePullRequest() (*cobra.Command, *Options) { | |||
cmd.Flags().StringVarP(&o.Head, "head", "", "", "the name of the branch where your changes are implemented") | |||
cmd.Flags().StringVarP(&o.Base, "base", "", "main", "the name of the branch you want the changes pulled into") | |||
|
|||
cmd.Flags().BoolVarP(&o.AllowUpdate, "allowUpdate", "", false, "if an open pull request from head branch to base branch exists, setting flag to true will update the pull request") |
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.
Probably best to lowercase this flag, i.e. --allow-update
so that it's consistent with other flags in jx CLI's
All looks good, just the one comment to change to lowercase, then just regen the docs and we'll be good to go. |
/ok-to-test |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rawlingsj The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@waciumawanjohi rebase ur PR with the latest master/main, afte #22 is merged. |
/test 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.
Few comments ...
assert.Equal(t, prs[0].Title, o.Title, "title not properly set") | ||
assert.Equal(t, prs[0].Body, o.Body, "body not properly set") | ||
} | ||
|
||
func createPRAgainWithoutAllowUpdate(t *testing.T, o *create_pr.Options, fullName string, scmClient *scm.Client, err error) { |
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.
may be use table driven tests instead?
if !updateAllowed { | ||
return false, 0 | ||
} | ||
pullRequestListOptions := scm.PullRequestListOptions{Page: 1, Size: 5000, Open: true, Closed: false} |
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.
Why 5000? Bit bucket for example sets the max at 100, so anything greater than that will result in bad request.
See (This was a workaround for bitbucket): https://github.com/jenkins-x/go-scm/pull/319/files#diff-d11bfd98e6b72330250844f3d1b2a7b94e88a4245870e9eb8bfcb58e2bef3918R48
I am not sure abt providers ...
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.
Why 5000?
I wanted a value that could reasonably assure that it wouldn't miss open PRs, particularly as the use case for this feature is an automated system (which could create many pull requests).
Bit bucket for example sets the max at 100
That is great context on constraints. Will noodle.
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.
Curious, should it be a configurable parameter from the cli? That way, users of different scm providers can set whichever value they want (according to the scm limits)
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.
Curious, should it be a configurable parameter from the cli? That way, users of different scm providers can set whichever value they want (according to the scm limits)
I don't think any user would understand why they would pass a page and size flag to a command to create a pull request.
Indeed, this make me wonder if the go-scm API is correct here. As a consumer of go-scm I expect to receive a slice of pull request objects. I would understand passing a length for that list (e.g. "Please provide me the most recent 50 or 500 PRs"). But questions of page or size limits should be the concern of the code within go-scm. Should the PullRequestListOptions be changed?
Alternatively, should the provider specific code for listing PRs in go-scm handle page
and size
values of 0, setting them to reasonable defaults for the given provider?
/hold EDIT: (u can switch unit tests to table driven in a subsequent PR, just the 5000 bit is something I am unsure abt ...). Remove the hold after you have figured out if 5000 will break anything for other providers (including github/gitlab). |
08ab2d9
to
ac69301
Compare
New changes are detected. LGTM label has been removed. |
I've been able to create a pull request and then update that pull request for repositories in both github and gitlab using the |
github and gitlab should be fine (we anyways test with only github atm with automated tests). It would be good to test with bitbucket cloud (did u check the limits), but we can look at that later. |
I've been trying to figure out how to work with bitbucket cloud at all. What is your workflow for generating a personal access token for bitbucket cloud?
|
|
I decided to stop fighting the pagination and just use it. So the ridiculously large One open question is how the different scm providers use that
What will be the behavior when calling
? Will it return the 2 open PRs in the single page? Or will it return PR #12 and not PR #1 (because PR #1 is outside the pagination). I tested manually against Github and it returns the 2 open PRs. But I don't know about the implementation of all other SCMs. |
My test command is:
Run twice, it should succeed both times. edit to add gitlab command:
|
This PR is blocked on this fix in go-scm: |
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
/hold cancel |
Automated use of jx-scm may lead to repeated calls to create a PR between
feature
branch andmain
branch. If an existing PR exists between these two branches, the create call will fail. Users may prefer that the existing PR is simply updated. These changes enable that behavior by adding an option--allowUpdate
flag.The new tests rely on code in this PR in go-scm.