Add Jira Connect branches controller
What does this MR do?
This MR is part 3/3 for #2647 (closed). For a full-context MR (all of these MRs combined), see !64890 (closed).
In this MR, we add the backend, namely:
- a new controller,
branches_controller.rb
- The Haml template for the
jira_connect/branches/new
route - Add the JS file to initialize the Vue app
- A feature flag and specs.
UX will be reviewed in the full-context MR: !64890 (closed). Any required changes as a result of the UX review will be made in follow-up MRs.
jira_connect_create_branch
, disabled by default and scoped to user
actor.
Manual Testing
-
Setup a Jira Cloud instance.
-
Open this branch in Gitpod.
-
Install the app manually in Jira from the Gitpod URL (
/-/jira_connect/app_descriptor
). -
Open a Jira issue and check that the "Create branch" action doesn't show up.
-
Enable the FF in Gitpod and reinstall the app.
-
Open a Jira issue and see the "Create branch" action in the right sidebar:
-
Click it, create a branch, and once it's synced back to Jira reopen the issue and see the branch(es):
-
Click the dropdown menu to create another branch:
To do
- [-] Need to provide the Jira URL to the frontend, so that we can give the user the option to return to Jira.
-
Tests, probably a feature spec to test the whole flow, and some basic unit tests for the controller. The frontend parts look like they already have solid coverage! 👍 -
Some refactoring to reuse code from normal issues. -
A feature flag check. - Since the feature is enabled through the app descriptor I'm not sure how this will behave, but according to https://developer.atlassian.com/cloud/jira/platform/connect-app-descriptor/#app-descriptor-updates Jira will regularly poll the app descriptor and publish a new version when it changes, so I think this should work.
Iteration | MR |
---|---|
1. frontend Add supporting Vue components | !66034 (merged) |
2. frontend Add the parent Vue app and initialization JS | !66036 (merged) |
3. backend Add the backend |
|
Screenshots or Screencasts (strongly suggested)
Happy path:
Does this MR meet the acceptance criteria?
Conformity
-
I have included changelog trailers, or none are needed. (Does this MR need a changelog?) - [-] I have added/updated documentation, or it's not needed. (Is documentation required?)
- [-] I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?)
- [-] I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?)
-
I have self-reviewed this MR per code review guidelines. -
This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines) -
I have followed the style guides. -
This change is backwards compatible across updates, or this does not apply.
Availability and Testing
-
I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.) - [-] I have tested this MR in all supported browsers, or it's not needed.
- [-] I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.
Related to #2647 (closed)