I am looking into improving the workflow my colleague and myself are using for BitBucket. Something that is often forgotten is the documentation for the feature we are working on therefore I thought I good way to 'don't forget' would be to add a Task as soon as a Pull request is created for a particular branch.
The first think a developer should do after creating the Pull Request would be:
- Add a comment, something like WIP (Work in Progress)
- Create a task underneath, something like 'Add documentation'
In this way, we won't be able to 'Merge' the branch into 'Develop' if All tasks are not completed (this is how it is currenly configured).
Rather than having the developer to do so, it would be good if we can have the system to do so as soon as we create the Pull Request.
Is that possible?
I had searchd on Internet, to be honest I didn't understand if taht functionality comes with like the Premium package or if it is an Add-On...who knows.
Thanks :)
Atlassian recently added a 'Default Pull Request Tasks' feature to Bitbucket Cloud.
The same functionality was previously available as a Bitbucket app, but it was removed in May 2020. It's now a native feature.
Product announcement: https://bitbucket.org/blog/bitbucket-cloud-product-updates-august-2022
Feature details: https://bitbucket.org/blog/default-pull-request-tasks
You can try this. It is free for 30 days.
https://marketplace.atlassian.com/apps/1225598/default-tasks-for-pull-requests?tab=pricing&hosting=datacenter
I did not find any free solutions.
Related
I am trying to test ODL-SDNiApp and found it not updated since Helium on this page https://wiki.opendaylight.org/view/ODL-SDNiApp:User_Guide. So, is it still supported by Opendaylight? if not, please list me some useful tools or methods for inter SDN controller communication.
Thanks.
According to the project page https://wiki.opendaylight.org/view/ODL-SDNi_App:Main, it last participated in the Boron release but it doesn't look like it's been active since. You can try the project mailing list or contact the listed committers. If it is inactive as it appears, perhaps you might want to try to reboot it.
looking at https://developers.podio.com/doc/applications/update-an-app-field-22356
as the documentation states we cannot pass the new hidden_create_view_edit attribute to the API call. (FYI: I attempted to pass it anyway but the documentation is right, it does not take the hidden_create_view_edit into account).
Can you please listen for this parameter? And in what timeframe would this become available? I need this to clone a ton of app fields with right settings.
Thanks for reporting this. It seems that we haven't included support for this specific method while implementing great new attribute hidden_create_view_edit. This is now fixed and planned for public release some time during next week.
Does anyone know how to create a branch using the VSO Api. The documentation for Branches doesn't include a "create".
I have been experimenting with doing it via the ChangeSet Api without much success.
This is TFVC, not Git.
Just as what you see in "Branches" page, there isn't any way to create branch with the Rest API. And mostly, you can only read/get the information with the Version Control API for now.
I would recommend you to use Client Object Model Reference if you want to manage the Version Control programmatically. To create a branch, use the "CreateBranch()" method in Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer class.
The REST API apparently does allow one to create branches.
The confusion is that people think that this would be a PUT operation on the Branches endpoint of some kind.
It is not.
In the REST API, a branch is just one more kind of change that is checked in as part of a changeset.
It took me a long time to discover this, myself; and I was using the old SOAP API in the belief, shared by everyone else it appears from what I can find in Q&As on the WWW, that this wasn't part of the REST API.
Of course, using the SOAP API prohibits using .NET 5, because the assemblies only come for .NET Framework.
An abandonware API on an abandonware runtime is not a satisfactory way to talk to source control. ☺
The terrible Azure DevOps documentation gives no clue as to this, except for 1 obscure not-even-a-complete-sentence hidden in a minor class: "List of merge sources in case of rename or branch creation."
The only other clue is what appears in the JSON, from a get changeset changes, that describes the changeset of an already-made branch.
The (also abandoned) Azure DevOps sample code does not contain examples for even deleting an item, let alone branching.
Changesets are checked in via the changeset creation endpoint.
The individual change is a TfvcChange in the changeset's list of changes where:
the version control type (which is a set of flags) contains the branch flag; and
the merge source for the change specifies the source item and the range of changeset numbers.
Branching an entire tree appears to be a matter of branching the directory and all of the files and directories in the directory.
In C♯ or PowerShell, this is a TfvcChange with a VersionControlChangeType of Branch, in a TfvcChangeset passed to TfvcHttpClientBase.CreateChangesetAsync().
I'm looking to use AtTask's API to update or create a custom field (ie. assign a custom ID apart from AtTask's auto-generated id) whenever a project is created through the web app. But I have not found anything about handling events in the API documentation.
I'm able to retrieve/edit project fields when issuing a request by ID or some other search parameter.
But I'm having trouble finding ways to edit project fields on some event like 'project created'.
One way I can think of is to have my script periodically search for new projects based on project metadata and edit projects that way, but there must be a better solution I probably missed.
Thanks in advance!
UPDATE:
It seems 'AtTask event subscriptions' was what I was looking for. At the time of the post below (12/2013), due to scalability issues, AtTask has turned this feature turned off with no ETA on resolving the issue. See here: Does AtTask event subscription work?
Any updates would be appreciated.
You are correct the AtTask API does not currently support events. The easiest thing to do is to just poll the system for updates using the search. You could also monitor an email address for emails that are sent upon project creation. The email will contain the project/task/issue ID that you can use to update events.
I am looking for a way to add a post-commit or pre-commit hook to my VCS that will allow me to both create and close a trac ticket in one go.
The use-case is for when a bug has been found, and corrected, but a single developer who wants to make sure the project manager can see the fix has been done, when it was done and what milestone the fix has been done in.
We have a default milestone in trac when creating a ticket, so reflecting that information would be good too.
I recommend extending TracTicketChangesetsPlugin to do this.
You would adjust the way it detects the command in the commit message (see http://trac-hacks.org/browser/tracticketchangesetsplugin/trunk/ticketchangesets/commit_updater.py?rev=8114#L154), as you would not have a ticket number to refer to yet.
See http://trac-hacks.org/browser/tracticketchangesetsplugin/trunk/ticketchangesets/commit_updater.py?rev=8114#L215 for where it actually does the parsing. You would have to return some new token to represent "new ticket."
The code that actually changes the tickets is at http://trac-hacks.org/browser/tracticketchangesetsplugin/trunk/ticketchangesets/commit_updater.py?rev=8114#L234 , so here would you create NEW ticket, then close it straight away. To create a new ticket, call Ticket(self.env) and then save it with Ticket.insert() (see http://trac.edgewall.org/browser/trunk/trac/ticket/model.py?rev=9692#L174 ).
If you do this, I recommend attaching your patch to a new ticket at Trac Hacks.
Create a post-commit hook. Notice how the trac post-commit hooks work and copy this functionality to control this action (creation + closing ticket). The creation + closing are two separate http requests that can happen with wget, you can intercept the ticket creation form's post, look at how the existing trac integration works, or hack it some other way. Have fun. I wish this could be more specific but it really does depend on what you're trying to do.