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.
Related
Please read carefully as I believe my use case is unique and I have tried searching a lot on how to do this, but I am still unsure.
Generally, I am trying to set up a repo for a group of developers to work on and have it contain CI checks and require reviewers. However, I have run into some issues with how Github enforces branch protection. On top of that, I cannot use Actions as we are using a self-hosted Enterprise Github through an organization.
My desires:
Use Jenkins (which is already set up and building) builds as checks for PRs. If the checks don't pass, you cannot click merge on the PR.
Allow pushing to a branch that I have a PR up for so the author can push changes based on PR comments.
Require two approvals from maintainers. You cannot click merge without these.
It seems I could protect a master branch for example. However, I would like to enforce the PR checks whenever a person chooses to make a PR. For example, from one dev branch into another dev branch.
Use case:
An author sets up a PR for merging a branch some-work into dev. Jenkins builds the HEAD of the branch some-work to evaluate the checks. I would like to enforce this PR to have two approvals from maintainers. So, those reviewers make some comments and request some changes. The author makes those changes and pushes a new commit to the some-work branch. Jenkins runs on the new HEAD to reevaluate the checks. Then, if-and-only-if the two reviewers approve and the checks pass can the merge button be clicked.
What I have tried:
Using Github branch protections: the required approvals and the required status checks. However, this prevents any pushing or force pushing to the branch being developed on. I could just apply these protections to master, but I also want these checks part of any PR (even dev2->dev1, for example).
Github actions, but these are not available in the self-hosted enterprise Github I have to use.
What I understand:
I understand that I can protect master, for example, in this manner with the native Github branch protection. However, if I want master to be something that always works, it is understandable that developers would break up a feature into multiple branches. They would also want their follow developers to review it when merging it from their branch to an intermediate (non-master) branch. Then the actual branch being merged into master consists of code written by many developers.
Thank you all in advance for your time and help. :)
Using Github branch protections: the required approvals and the required status checks.
However, this prevents any pushing or force pushing to the branch being developed on
But... that issue (not being able to push a protected branch) could be part of a possible solution.
I would make jenkins create/reset a PR branch based on a push on a topic branch (like some-work-pr, based on some-work)
some-work is not protected, and can receive commits at any time
some-work-pr is created by Jenkins protected, and cannot be modified: compilation/test/review/approval happens here.
PR would only be done from xxx-pr branches (protected PR branches created/managed by Jenkins), while other topic branches continue to evolve.
You can only enforce these policies with branch protections, so if you want to enable required CI checks before merging a PR for all branches, then you need to protect all branches (e.g., with the pattern **). In that case, you'll need to have developers use a forking model for your repositories so that they can push code to their forks and then merge in the changes via pull requests only.
Note that if you adopt an approach where projects are implemented as a set of small, incremental changes that are merged frequently and use feature flags to control whether the code is enabled, then as a practical matter developers will only merge into the main branch and you can get away with only protecting the main branch.
In TFS, when I link a work item in a PR, the PR gets approved, merged and the a CI deployment is performed, then I bet TFS should be able to see that the linked workitem(s) have been deployed production. I shouldn't have to look into master or develop branch to see if the code I am looking for is in place.
So, when looking at that particular work item (in epic, on board, wherever) I should be able to see some kind of deployment status.
Is that an out-of-the-box feature or does that require a plugin?
Actually the "deployment status" can be checked with the linked Pull Request and commit.
Once the PR gets approved, merged and the CI deployment is performed, the code changes will be checked in. Normally we can check if the code changes are really there by navigating to the specific merged branch.
Actually, when you looking at that particular work item, you can check the linked PR and commit to know the deployment status.
When you link a work item in a PR which is not approved and
completed, then you can see that there is only a Pull
Request with the ID under the All Links tap in the work item.
Once the PR is approved and completed, you can see that there is a
commit linked to the work item.
So, when you see a corresponding Commit linked there, that means the changes are deployed. You can also double click the linked PR and commit to open them to see the change details.
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.
We're using TFS for our day-to-day work management, but are currently unable to use it for source control - we're using SVN instead.
I would like to nonetheless ensure that all our work items have been code reviewed before being closed, and that any code review actions have been followed up on. Any recommendations on how we can keep track of this using TFS with minimal manual steps?
I am also concerned with ensuring that the code review step has not been skipped, and auditability of whether it has happened and whether all resulting actions were closed off. If I look at a closed task, how can I easily tell that a code review occurred on it?
(Optional) Require that every SVN change refer to a work item number in TFS with the check-in comments.
The work item in TFS has a "LINKS" tab on it. As soon as the code is checked in, another work item of type "Task" (or whatever you want to use for code reviews) should be created and linked to the primary work item on this LINKS tab to request the code review for that work item. It should refer to the SVN revision number(s) that need(s) review.
I'm not very familiar with SVN, but I assume there is a way to have branches that could be used as follows. Maintain a separate branch for reviewed code. Only code reviewers can merge into that branch. The only way code can get in there is if the proper work item in TFS exists, and a code reviewer approves and merges the code for it. I'm used to Mercurial and TFS where merging code is really easy. If merging is not easy in SVN, a different solution may be required.
If the linked task exists on a work item, then you know that the code has been checked in and code review is in process. If the link exists, and the linked work item is resolved, then you know the code review is complete. If the link does not exist, then you know that code has not been checked in for this work item (or at least it's not in the reviewed code branch, and has no intent to be there).
We have decided to edit the TFS workflow to include an extra 'In Review' state after 'Resolved'. This allows us to use the existing task board without any overhead of creating separate review tasks, or having to edit the task title to be 'in review: ....
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