In the behaviours overview doc of scriptrunner, it states:
To create a new Behaviour. Go to the Administration screen, and click
the Behaviours link in the Behaviours section, or press gg or . and
type Behaviours.
I've installed scriptrunner trial version, but have no idea how to access that administration screen (the keyboard shortcut doesn't work either)
note: i'm using jira cloud
any ideas?
You are looking at Server Documentation. I believe Cloud Documentation is here and with quick look I couldn't find the section Behaviour. It might be part of their limitation for Cloud version. Take note that, Cloud plugins are using Atlassian Connect and technically it has more limitation in compare to server land.
Related
I have integrated JIRA as third party bug tracker in locally deployed TCMS.
as per steps mentioned in the doc
Integration is successful.
After this step, when i proceed to searching bug (Home > Search > Search bugs). TCMS does not list any products/components/version from JIRA !.
I did disable the default bug tracker (with below env variable)
>>> os.environ.get("KIWI_DISABLE_BUGTRACKER") 'yes'
Am i missing something here? help me if there are additional configurations.
I have integrated JIRA as third party bug tracker in locally deployed TCMS. as per steps mentioned in the doc
If you read the documentation more closely at the top of the above page you will find:
The extent of integration with 3rd party bug tracking systems is documented in tcms.issuetracker.
which tells you that the functionality you are looking for is not currently supported. If you wish this functionality to be considered for a future release you can open a feature request at https://github.com/kiwitcms/Kiwi/issues/new/choose
"Search bugs" is to query the internal bug tracker which you have disabled and this is not related to Jira.
I am interested in any information about or experiences with deploying PowerApps solutions to new environments within the same tenant.
In my solution I have a canvas-app and several flows between the app and sharepoint. I have used connection references to all connections (sharepoint, mail, etc.). On the devops side I have a build pipeline from my development environment, very much in line with Microsoft's recommendations for ALM. In addition, I have a release pipeline to publish the solution in another environment, e.g. a test environment. I can publish the release but when I access the solution in the new environment all flows have been turned off and all connections to sharepoint have been severed. When I inspect the flows it throws an error that it was unable to locate the connection Id. What strikes me as odd here is that the connection references that are visible in the new solution cannot be selected. However, what I can do is to add a new connection (from each flow), whereafter I can turn the flow back on and activate each of them in the canvas app.
What I am asking for here, is any documentation, guide, tutorial, help, etc. to make this release a little more automatic, so I won't have to re-add connections for every single action from each of my flows.
I think you are in luck 😊 and you should check out the latest PA community call. I think the last demo is the thing you are looking for (especially from that moment I suppose🤔) and is now one of the targets in Power Platform.
If you are considering to introduce source control as well (like git), currently there is a cool experiment going on in the community in that direction which I think is quite promising and you may check this article. But please consider this pack/unpack tool as an experiment and don't just remove the original .msapp files yet 😉.
I think I have finally found a working solution. I'll document my steps here for other ALM hopefuls.
When pushing to the target environment for the first time I need to click on each of the connection references, click on solutions layers, ) use the breadcrumb path to go one step back ] and from here I can assign the correct connection. Subsequent deployments now work without any hassle.
Also, first time deployment, I have learned cannot activate workflows. However, future deployments can activate workflows by managing the setting the the Import Solution build tool
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.
I installed JIRA 6.4. I also Crerated Project and Issue in it. I assigned Issue to some user. Now If Administrator wants to monitor isssue status, he can see progress. But how does the asignee i.e the person working on issue update issue status. Actually I am very new to JIRA. Or is there any other plugin for it
Depending on the workflow you have configured for the project, the assignee should see action buttons on the issue that they can click to progress status; e.g. "Resolve Issue" or "Close Issue". These are known as "Transitions" in the workflow and configure how issues can move between certain states.
If you're also using the JIRA Agile add-on, you can create a "Rapid Board" that allows assignees to drag and drop issues between states to create a "Work in Progress" board.
This is just a starter, it's best to run through the tutorials from Atlassian, they will take into account the various project setups that may apply to you.
Also, if you're just getting up and running with JIRA, it may be advisable to upgrade to JIRA Core 7 (or JIRA Software if you require the extra features) as it has project templates/workflows that will make getting up and running a lot quicker.
We have self hosted GitLab CE and Jira, we want
link git commit with jira issue
link git commit with jira issue status, like we can start/move/close issue by git issues
limit above operations on specific branches, e.g., change issue status only when commits on master branch since we perform merge request for every single feature/bug
but only GitLab EE built-in supports Jira integration, how could I do that for GitLab CE?
I'm on GitLab CE 7.8.2, Jira+Agile 6.4
I think there is now a better way:
https://docs.gitlab.com/ce/user/project/integrations/jira.html
GitLab can be configured to interact with JIRA. Configuration happens via user name and password. Connecting to a JIRA server via CAS is not possible.
Each project can be configured to connect to a different JIRA instance, see the configuration section. If you have one JIRA instance you can pre-fill the settings page with a default template. To configure the template see the Services Templates document.
Once the project is connected to JIRA, you can reference and close the issues in JIRA directly from GitLab.
You can take a look at this project : https://github.com/akraxx/gitlab-jira-integration. It's a Java application, so you will need a server with a JVM to run it.
Follow the README to know how to configure it :)
Note that, with GitLab 13.3 (August 2020), you don't have to setup a third-party integration on each project anymore.
You can do so at your managed Gitlab instance level (free edition).
Instance-level project integration management for external services
Administrators of self-managed GitLab can now integrate third-party services with all projects on the instance from a single interface.
Previously, integrations had to be configured per project, which meant that if an instance had thousands of projects, thousands of individual configurations had to be manually configured. Not only was this time-consuming, but it was also error-prone, hard to update, and made it difficult to enforce integrations as a policy.
By configuring integrations across all projects, administrators save themselves and their project owners incredible amounts of time and effort.
This is the first iteration of this functionality. In upcoming releases, we will expand this feature to the group level, add more configuration and compliance options, and more.
See Documentation and Issue.
Plus, with GitLab 13.4 (September 2020)
GitLab for Jira and DVCS Connector now in Core
For users of Jira GitLab, the GitLab for Jira app and the DVCS Connector
allow you to display information about GitLab
commits and merge requests directly in Jira.
Combined with our native
integration with Jira, you can easily move back and forth between the
two applications as you work.
These features were previously available only in our Premium plan, but
are now available to all users!
See Documentation and Issue.
See GitLab 13.6 (November 2020)
Group-level management of project integrations
In GitLab 13.3, we added the ability to enable an integration across an entire instance.
With GitLab 13.6, that feature is being expanded to allow integrations to be managed at the group level as well!
Group owners can now add an integration to a group, and that integration will be inherited by all projects under that group.
This has the potential for saving massive amounts of time, as many organizations have specific integrations that they want rolled out to every project they create.
A great example of this is using our Jira integration. If you’re using Jira, it’s almost always across the whole company. Some of these companies have thousands of projects and therefore had to configure each and every one of those integrations individually.
With group-level management of project integrations, you can add the integration at each parent group, reducing the amount of configuration required by orders of magnitude!
Read more in our announcement on the GitLab blog.
See Documentation and Epic.
With GitLab 13.10 (March 2021):
View Jira issue details in GitLab
Users of our Jira issue list feature can now view the details of an issue directly inside of GitLab! This MVC enables developers to see the details, labels, and comments on an issue, giving them the ability to stay in GitLab while working on Jira issues.
Our goal is to empower developers to stay inside of GitLab during the majority of their day, and this is now one less trip to Jira you’ll have to make.
In GitLab 13.10, this feature is available if you enable a feature flag. This feature will be enabled by default in GitLab 13.11.
See Documentation and Epic.
At the moment I think the GitLab Listener add-on for JIRA is the only way to integrate GitLab CE and JIRA. You can use commit messages to generate JIRA worklogs, comments and activities, as well as execute workflow transitions. The add-on also tries to map GitLab users to JIRA users in order to link worklogs, comments, etc. to the right user.
It's a simple add-on and maybe it does not cover all your requirements, but it's better than nothing :).