Hi Lukasz, We don't often do a lot of community support over the weekend (we're stationed in California, USA), which is why you haven't heard from us. We answer community support as soon as we can, but private paid support and some development/business priorities sometimes delay that. I know sometimes people have questions/need support that's time-critical, blocking something they need to do, and for that we have some other support options I can reach out to you about, if you're interested.
If -u is prompting, it's because it's not confident that the commit(s) you're working with match a specific review request. -u looks at the HEAD commit's summary and description and tries to find a pending review request with the exact same text. If it finds an exact match, it uses it without prompting. If it doesn't find an exact match, it has to prompt because it might get things wrong. A lot of that depends on your workflow. If a developer is always amending one single commit on their branch, keeping the same summary/description, it will find the review request. On the other hand, if there's multiple commits on the branch, or the summary/description on the commit or review request changes, it's not going to work right now. We also can't trust the commit SHA on Git, since it changes every time the commit contents, description, or position in the tree changes, so we can't always use it as a lookup (though we do factor that in with -u). We've explored using git-notes to attach the review request ID, but it's not an ideal solution, posing new problems. We're going to look into setting the review request ID in the branch description (git branch --edit-description), but there's no code toward this yet. -r is fine to use, though. We're never getting rid of it. It will require something on your end to figure out that ID. Since -u is just a wrapper around -r, it'll be where any new intelligence for finding a review request would live on our end. There isn't something else we could provide that would give you a value for -r. I know some companies have their own wrappers around RBTools, and I think some have their own internal method for tracking branches and review request IDs. I don't have access to any of these, and couldn't say how they work. You could always provide your own wrapper and try the method of attaching some information to the branch description using `git branch --edit-description`, like we're looking into, but you'd need to figure out the logistics around it, and a lot of that will depend on your workflows at your company. Christian On Sun, Oct 28, 2018 at 10:59 PM Lukasz <[email protected]> wrote: > @Christian Hammond, @RB/RBT Developers/Users: creating review requests > with updates in GIT hook is a very important part of our process and we are > stuck in it. > > Could you give us any response or should we ask on Reviewboard-Community > group? > Maybe some part of our post is not understandable? > > Regards, > Lukasz > > W dniu piątek, 26 października 2018 09:54:48 UTC+2 użytkownik Lukasz > napisał: >> >> Hello All! >> I have a question related to RBTools app (version 1.0.1). >> >> We have the following workflow - user pushes his changes to some >> defect/task branch (GIT) and post-receive hook calling RBT (post) creates a >> new review request in ReviewBoard (3.0.9). >> >> It's OK by the time when developer decides to push some new changes or >> fix to the same GIT branch. We expect that previously created review >> request would be updated with new revision and the same ID, but instead we >> have another review request with new ID. >> >> We are using the following command: >> >> rbt post --debug --publish --submit-as={user_id} --server=http://{RB_url} >> --username={user_id} --password={user_passwd} --disable-proxy >> --repository={repo_name} --branch=master --bugs-closed={defect_branch} >> --target-people={user_id} master..{defect_branch} >> >> >> We tested* --update* option but it's doesn't match proper review request >> ID and whats more - asking for update confirmation (we need a "silent" call >> without user prompt). >> >> Best option would be to use *-r {review_request_id}* argument, but there >> are several issues: >> >> 1. It's not the recommended way according to your blog: >> https://blog.beanbaginc.com/2014/12/08/5-tips-for-your-rbtools-workflow/ >> ("*It’s much nicer. Get in the habit of using -u**. It’s the wave of >> the future.*"). >> >> 2. We need to know the *review request ID *for the particular >> defect/task branch. What is the best way to get it without our changes, >> using built-in methods? Via RB API? We haven't found any useful examples. >> >> To sum up, we want to use RBT command in GIT post-receive hook, which >> creates new review request in ReviewBoard if changes are pushed for >> defect/task branch for the first time and updates this review request with >> new revisions for each GIT push on this branch (without user confirmation: >> Update? Yes/No). >> >> We would be grateful for any help or example - how the RBT command line >> should looks like. >> >> Best regards, >> Lukasz >> >> >> >> -- > Supercharge your Review Board with Power Pack: > https://www.reviewboard.org/powerpack/ > Want us to host Review Board for you? Check out RBCommons: > https://rbcommons.com/ > Happy user? Let us know! https://www.reviewboard.org/users/ > --- > You received this message because you are subscribed to the Google Groups > "Review Board Community" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Christian Hammond President/CEO of Beanbag <https://www.beanbaginc.com/> Makers of Review Board <https://www.reviewboard.org/> -- Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/ Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/ Happy user? Let us know! https://www.reviewboard.org/users/ --- You received this message because you are subscribed to the Google Groups "Review Board Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
