Approve Pull Request after they been merged on BitBucket cloud - bitbucket

Usually due to time constraint I found very useful the change to review and approved post-mortem Pull Requests.
Using BitBucket cloud version it was possible to do that a couple of months ago.
With the latest updates is not possible anymore.
Not sure it this is a setting or is a behaviour that can not be customized at all.

Related

How to sign up for Jira?

Is this correct that Jira is installed on one's server or local computer and that's the only way to run it?
If not, how can I run, or connect to, Jira on Atlassian's server?
Namely, at this point I don't want to install anything on my VPS or computer, and instead I want to be able to run Jira in the cloud, the same way I'd sigu up for and then use bitbucket or github. That is, by creating an account. I need Jira for a couple of days only, to test some REST API.
Where does one sign up for Jira? There's no way, is there?
At the current time Atlassian provides a free plan for its Jira cloud service.
See here: https://www.atlassian.com/software/jira/pricing

Azure DevOps Server does not update pages with Live updates

Since we updated from TFS to Azure DevOps Server 2020 we have a problem with live updates when using the client. I expect pages to automatically update with new information as they come available like it did with TFS, but that doesn't happened anymore. Instead we get an error:
'Live updates for this pull request were temporarily interrupted. Refresh to view the latest.'
I suspect it is a problem with a server setting, but I have no idea where to look.
Azure DevOps Server
Version Dev18.M170.4

How do you keep track of deployment ids and builds

Currently I am working in a project where we have 8 instances accross different geographies. We currently use bmc rlm ( https://docs.bmc.com/docs/ReleaseLifecycleMgt/50 ) for deployment automation.
However to keep track of our deployment ids we are using excel.
Starting from Dev environment , to QA environment ( each region has
its own QA and schedule ) and ultimately move to Production.
What I wanted to know was , is there any tool that you use to keep
track of deployments ?
We tried using sharepoint but it is kind of limiting in the features.
We would ideally like a workflow to be created , whereby developers
submit the request with the dev deployment id.
Workflow goes to Release Approver for QA env. Once he/she approves ,
QA testing team gets notified.
Please let us know if anybody else faced this kind of issue and used some tools for the same?
We have recently started public preview of Reliza Hub https://relizahub.com which aims to solve this problem.
Some of the functionality you are asking (particularly approvals) is not there yet, but it's coming. Tracking functionality and mapping instance to releases is there already.
Currently I'm trying to add documentation as we go, so far Version Increment workflow is documented here. And functionality to send release data to Reliza Hub is documented in our client github.
Would be happy to provide support and discuss incomplete or missing features via our new reddit channel r/Reliza.

Jenkins and GitLab -- Gitlab Hook plugin is the right choice?

There are so many posts about this, and being inexperienced in Git doesn't help to get a good grip on this.
I just joined a new company that dont have CI at all, so jumped on the opportunity to create a proof of concept (using Jenkins locally on my Windows box for now, until I get a dedicated server for it). I've used and semi-configured Jenkins in the past, using SVN, and it was so simple and fast to get it working. In this company, they don't use SVN, only GitLab (I believe its private - we have our own site, not .gitlab.com), and nothing works for me.
I followed a few turorials, but mainly this seemed like the one that meets my needs. It didn't work (the reasons and symptoms are probably worth a post of its own).
When I look at Gitlab Hook plugin in Jenkins, I see a big red warning saying it is not safe ("Gitlab API token stored and displayed in plain text").
So my question, for this POC that i am working on, how serious is this warning? Should I avoid this plugin and then this method altogether because of this?
And while i'm at it, I might also throw an additional general question to open up my options here ... If I want Jenkins to work with Gitlab (meaning, I checkin something and it triggers a build), do I absolutely need to use the SSH method, or it could work with HTTPS as well?
Thank you.
This is indeed SECURITY-263 / CVE-2018-1000196
Gitlab Hook Plugin does not encrypt the Gitlab API token used to access Gitlab. This can be used by users with master file system access to obtain GitHub credentials.
Additionally, the Gitlab API token round-trips in its plaintext form, and is displayed in a regular text field to users with Overall/Administer permission. This exposes the API token to people viewing a Jenkins administrator’s screen, browser extensions, cross-site scripting vulnerabilities, etc.
As of publication of this advisory, there is no fix.
So:
how serious is this warning?
Serious, but it does require access to the Jenkins server filesystem, or it requires Jenkins administration level. So that risk can be documented, acknowledged and, for now, set aside, provided mitigation steps are in place, ie.:
the access to the Jenkins server is properly monitored
the list of Jenkins admin account is properly and regularly reviewed.
do I absolutely need to use the SSH method, or it could work with HTTPS as well?
You can use https for accessing GitLab repositories in a Jenkins job.
But for the GitLab hook plugin, SSH remains the recommended way, considering you would use a token (instead of a user account name/password), that you can revoke at any time.

Synchronize Issues in Mantis and in JIRA

We are moving from Mantis to JIRA and wish to keep Mantis alive for some time until the migration is complete and all the users are migrated.
All users (esp. the dev team) that have been migrated to JIRA shouldn't continue with Mantis (maybe deactivate accounts) and concentrate on JIRA alone.
Thus if a Mantis issue that was migrated to JIRA gets fixed/commented (in JIRA) the new status should be synchronized to the still existing Mantis issue.
And (if possible) new issues that are created in Mantis should be automatically be added to JIRA (if this is not possible then thats OK too)
Does anybody know of a tool or plugin that can do this?
I do not know any tool that does it, but in our company we have successfully implemented sync tool for Jira<->Footprints and Jira<->CRM. It would use Jira SOAP API (or REST starting from 5.0) and Mantis SOAP API. This tool can regularly check issues in both systems and update them accordingly.
Jira SOAP API - http://docs.atlassian.com/software/jira/docs/api/rpc-jira-plugin/latest/index.html?com/atlassian/jira/rpc/soap/JiraSoapService.html
Jira REST API - https://developer.atlassian.com/display/JIRADEV/JIRA+REST+APIs
you can implement your own sync using Jira's REST API as #Daria replied above, or you can use Task Adapter for manual data synchronization between Jira and Mantis.
Sorry I have no immediate answer, but we are developing an internal tool for exactly this purpose:
migrate existing issues from Mantis -> JIRA
ability to enter new issues in Mantis and have them synced to JIRA
activity in JIRA issues replicated back to Mantis
workflow disabled in Mantis (issues are slaved to JIRA state)
keep Mantis alive for N months while users are trained and migrated
It is using their SOAP and REST APis respectively.
If there is interest and it works well (looking really good at this stage) I will seek permission to open source it.

Resources