I would like to exploit the integration between the two tools to be able to automatically create a branch in GitLab for every new Bug or Feature ticket created in Jira.
I would like to know if (i) it is possible; (ii) what is the link between the two tools (I guess the unique ID number assigned by Jira); (iii) assuming the first point is true, what happens to the created branch when I close the Jira issue (e.g. I've mistakenly created a bug fix that was not needed).
I've used Jira in conjunction with GitHub so I'll try my best to help you.
I) This is definitely possible.
II) We used to use the unique ID given to a ticket and include it within in the branch name this creates a link between both tools. Any changes committed on the branch will be shown in JIRA.
III) From experience when this happens the branch will persist and will need to be deleted manually using a console we used to use a .git console and used a delete command.
I also found through a quick google search some documentation on GitLab on integration with JIRA as well as some insight on creating branches.
Doc - https://docs.gitlab.com/ee/user/project/integrations/jira.html
Branch - https://gitlab.com/gitlab-org/gitlab-ce/issues/3886
Hope this helps.
Related
I spent a lot of time describing my changes in a PR in Atlassian Bitbucket online, but my PC blue-screened before I could create the PR. Is there any way I can recover the description? If not through Bitbucket, perhaps through Google Chrome?
I tried looking in the repo's list of existing (created) PRs. I also tried creating a new PR from scratch with the same settings, hoping the description that I'd spent so much time on would automatically populate (Atlassian does that sometimes), but no luck.
Sadly, the answer is probably not.
One major downside of BitBucket's Pull Request feature (compared to competitors like GitHub) is that it lacks a Draft PR capability to explicitly mark a PR as not yet ready for review. The description information in the Create PR interface for BitBucket Cloud only exists in your browser until you click "Create Pull Request" for the first time. You CAN continue to edit the description after creating the PR, but some developers prefer not to "edit in public".
As an added complication you might not yet have seen, even without a browser crash you can get into trouble in the Create PR interface if the source branch changes. I.e. pushing additional commits to a source branch while you're editing the description in the Create PR interface for that branch gives you a popup with two options, BOTH of which result in the loss of your current description text.
Other alternatives:
Craft your description text in a private editor (possibly one with markdown capabilities) and save to your local disk, then paste into the BitBucket Create PR description box as the last step. This is probably the most reliable solution.
Adopt a naming convention with your repo reviewers for PRs. For example in our team, PR's with a Title prefixed by "WIP:" are understood as work-in-progress that is not yet ready for review.
I am new to Azure DevOps, so perhaps this is a really simple question. When selecting a build (there are many) to deploy to production, it would be great if I could identify the user stories or tasks were included in that build. I want to be able to say what work is being deployed before it is live, or tell customers who are waiting for new features when that feature is live.
I have tried to write a script using the Azure DevOps API and can see my builds and pull requests. But how do I link them? Is there an existing tool to do this maybe? It would also be great to say given a user story id (e.g. 171171), you could say which build it appears in. Is this possible or do this without saving all of the data from the API and reading this cached version?
You can specify work items (Bugs, User Storys, ...) when commiting to the Git-Repo. This is done by Hashtag and the work item number (e.g. #1234). Visual Studio also has a UI support for this, which does the same.
The linked work items will automatically be display at the Build summery page.
Just add work items into commit. Here is different options: Linking Work Items to Git Branches, Commits, and Pull Requests
I am investigating a way to automate some of our build processes using Jenkins and HPQC. Currently, we have a process where, once a change to fix a defect has been checked in we set its status to "Fixed" and then reassign defect in HPQC from the individual developers to a team lead.
The team lead is tasked with manually deploying a build for the deliverable to the test environment and when he does this he will then update all of the defects assigned to him this way reassigning them to the test lead, who can assign them to individual testers.
I would like to automate this process where I can. Does HPQC have a web API of some kind? So that a remote system (such as a Jenkins build server) could run a post-build action script to gather a bunch of defect numbers (those included in the build) find each defect in HPQC and then update its status and owner?
There is a REST API for ALM / Quality Center, info is accessible:
http://support.openview.hp.com/selfsolve/manuals
You will have to sign up for an account with HP to access it. Ugh, troglodytes.
Search for "ALM REST API", download and read the newest guide and reference for your version of QC.
(We also use QC at my work. It's pretty damn bad. I should try and convince them to get or build something better.)
The answer above is a good one, I found the reference he mentions, but making use of that is not very intuitive, probably because I am such a newb. For my fellow unenlightened you might want to use another reference I found for how to use the reference :
http://www.consulting-bolte.de/index.php/22-hp-alm/hp-alm-rest-api/115-connect-to-hp-alm-via-java-using-rest-api
The key piece of information for me was that inside all of these class files they give you in the "Example Applications" folder there is a reference to a package :
package org.hp.qc.web.restapi.docexamples.docexamples.infrastructure;
This is just another name for all the files located in the guide in the "infrastructure" subfolder. You do not need to go find this out on github or something.
We have a JIRA instance installed on our side and our client is using that. Now client have purchased license of JIRA on Demand and want us to migrate their project from our JIRA to their.
Is there a way to achieve that?
Thanks in advance
Kaushik
Check out Altasian Splitting+a JIRA instance page:
Occasionally an organisation may need to split its existing JIRA instance into two separate instances. For example, there might be a requirement to have some particular projects in one JIRA instance, and other projects in a second instance.
Basicly, It's done by backing up the project and restoring it on the new server.
You will find a nice tutorial here:
http://www.jusuchyne.com/codingforme/2012/12/jira-migrating-certain-projects-from-instance/
As described here, there is a Plugin in the Atlassian Marketplace, that lets you copy the configuration: https://marketplace.atlassian.com/plugins/com.awnaba.projectconfigurator.projectconfigurator
I have installed Jira and the subversion plugin (with success from what i can tell from the administration panel - subv. plugin installed).
I then add a repository that I have created on the file system, BUT i cannot see an option which will link/connect a new or existing project to a SVN repository. What i want to do is link a project with a repository so I can track commits made to the project (link commits with issues). After some searching i found that this is possible but I cannot figure a way to do it.
Do I need another plugin for that? I have tried googling for the last hours but I cannot find anything related.
regards,
The way SVN-Jira linking works by default is to simply put the issue identifier of the Jira issue in the comment when committing to the SVN repository.
It can be helpful to enable comment editing in the repository, if you have past commits or users who forget to add comments when committing.
Example commit comment:
Fixed problem with login. See issue MYJIRAPROJECT-26 in issue tracker.
There's a service in Jira which scans the SVN repository at regular intervals, and builds a cache of any SVN revisions where an issue identifier appears. Depending on the polling interval, it make take a few minutes for the commit to show up in Jira.
The polling time is controlled by the JIRA Service for the SVN plugin. See Admin, Services.
~Matt
you can enforce that future subversion commits require a jira issue reference for more reliable--than relying on your programmer's word ;)--jira-subversion integration
the jira commit acceptance plugin can be configured to block commits that don't include a valid (defined by subversion-jira project mapping and/or regular expression as appropriate to your situation) jira issue reference in the commit comment
reliable jira-subversion linkage availability allows handy stuff like:
Integration with issue trackers