Skip to content
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

Allow updating a task's status to RESOLVED or OPEN #188

Merged
merged 21 commits into from
Apr 2, 2019

Conversation

ftclausen
Copy link
Contributor

closes #175

This is my first take at allowing a task's status to be changed after it has been made base on our discussions in the issue above. Not sure if it is what you had in mind; we can definitely change it as required.

Some notes

  • I created an UpdateTask class instead of CreateTaskUpdate because it seemed a less confusing name
  • Added mock tests to open task, resolve task and testing the error path
  • Added live test (against local Bitbucket instance using dev license). This is just one test that both opens and resolves a task. Seems easier than messing with test dependencies.
  • I could not get the live tests working with HTTP endpoints using just a username so modified TestUtilities to send the full user:pass string
  • Also modified TestUtilities to do a case insensitive comparison when trying to find the Bitbucket user

I'll comment some more inline.

@cdancy cdancy self-assigned this Mar 22, 2019
@cdancy cdancy added this to the v2.5.2 milestone Mar 22, 2019
@cdancy
Copy link
Owner

cdancy commented Mar 22, 2019

I created an UpdateTask class instead of CreateTaskUpdate because it seemed a less confusing name

FWIW: I only kept this naming convention because that's what jclouds uses and I wanted any folks familiar with that framework to be able to jump in here and hit the ground running. I personally don't care for the convention at all just did it for standards sake. With that in mind: I'm OK with this name :)

README.md Show resolved Hide resolved
Without the Anchor we need fewer calls
…al UpdateTask class

Now it is much simpler just to pass a string of the desired state and set the taskId in the URL
Intellij Idea likes to collapse down imports if there are many from the
same package but PMD does not like this. So I unexpand them but then
forgot to add the actual import.
assertThat(instanceReopened.errors().isEmpty()).isTrue();
assertThat(instanceReopened.state()).isEqualTo("OPEN");
}

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets also add another test to check when things fail. Maybe pass in a bogus taskId and ensure that the errors() object gets properly populated.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added an on failure test in 4ba5d22

@cdancy
Copy link
Owner

cdancy commented Mar 27, 2019

Looks good. Couple more comments to address and I think we should be good to go.

@ftclausen
Copy link
Contributor Author

Looks good. Couple more comments to address and I think we should be good to go.

I think have addressed the outstanding items but, as you might expect, I am used to working in Bitbucket so I may have missed something. Let me know if that is the case.

Once everything is looking OK I'll cleanup the feature branch history.

@cdancy
Copy link
Owner

cdancy commented Mar 28, 2019

@ftclausen everything LGTM. Going to run the integTests in a bit to confirm all works as expected but code-wise everything is good. As far as "cleaning up the branch and/or squashing" I've been not wanting to do that as of late. I've always like the idea, and have done so in my projects, but it removes the ability to be able to cherry-pick out and/or revert single commits. Does make the history look very clean but at the cost of being able to pin-point very specific commits. I would say leave things as-is and if all goes well with testing here I'll merge later today.

@ftclausen
Copy link
Contributor Author

@ftclausen everything LGTM. Going to run the integTests in a bit to confirm all works as expected but code-wise everything is good. As far as "cleaning up the branch and/or squashing" I've been not wanting to do that as of late. I've always like the idea, and have done so in my projects, but it removes the ability to be able to cherry-pick out and/or revert single commits. Does make the history look very clean but at the cost of being able to pin-point very specific commits. I would say leave things as-is and if all goes well with testing here I'll merge later today.

No worries about rewriting branch history - I'm fine to leave it as is. My integTest runs have been OK on a development instance of Bitbucket server 5.16.3 (not tried 6 yet).

@cdancy cdancy merged commit 4ba5d22 into cdancy:master Apr 2, 2019
@cdancy
Copy link
Owner

cdancy commented Apr 2, 2019

@ftclausen changes have been merged to master. I did have to revert your changes to TestUtilities as they were breaking for me. Otherwise everything else looks good.

@cdancy
Copy link
Owner

cdancy commented Apr 2, 2019

Version 2.5.2 has been released.

@ftclausen
Copy link
Contributor Author

@ftclausen changes have been merged to master. I did have to revert your changes to TestUtilities as they were breaking for me. Otherwise everything else looks good.

Great news, and no problem at all for reverting my changes. I'll figure out what was going on on my end when I get to the next contribution (fetching all tasks for a PR).

@cdancy
Copy link
Owner

cdancy commented Apr 11, 2019

@ftclausen sounds good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Discussion: Marking existing "RESOLVED" task as "OPEN".
2 participants