What's the difference between hooks and webhooks in BitBucket? I've read the documentation for both but I can't seem to understand when you would use one over the other.
Edit: Documentation that I read.
https://confluence.atlassian.com/bitbucket/manage-webhooks-735643732.html
https://confluence.atlassian.com/bitbucketserver/using-repository-hooks-776639836.html
As ben5556 mentioned, you're comparing Bitbucket Cloud documentation to Bitbucket Server documentation. There's another important distinction here, though: the Bitbucket Server docs you linked refer to git hooks, which are a native part of Git, and the Bitbucket Cloud docs refer to webhooks, which are an HTTP-based callback mechanism. (In the interest of full disclosure, Bitbucket Server can send webhooks as well: https://confluence.atlassian.com/bitbucketserver/managing-webhooks-in-bitbucket-server-938025878.html)
You can't currently control git hooks on Bitbucket Cloud, but on Bitbucket Server (where you'd only break your own stuff) you can use those to control different parts of the git workflow. For example, on BB Server, you can use a pre-receive hook to reject pushes if some commits don't have a ticket number in the commit message, or you can use a post-receive hook to notify your (human) users about upcoming maintenance.
Webhooks are typically used more as a notification method - you can have Bitbucket notify Slack about pull request merges, for example, or have Bitbucket notify your CI/CD system that there are new commits to test.
Both are same from what I understand. One refers to Bitbucket server while the other refers to Bitbucket cloud but in essence their purpose is same.
Related
I want to disable write access or any direct commit on release/* and main/master, the only way for these branches to get update is via merge/pull request coming from feature, hotfix, bugfix, or develop branches to avoid trouble. How can I enforce such rule? Currently exploring Branch permission.
While allowing everyone that has access to the repository a pull from release and main/master and direct commit only on feature, hotfix, bugfix, or develop branches
Not sure if my understanding and what I am doing is correct as other user aside from Bitwise can still direct push to master branch.
I am looking to trigger Jenkins's job from the Microsoft team's channel. Can anyone provide step by step implementation of this?
There are two nice options you can use:
Outgoing Webhook - Will scan for words in the chats and send a notification to your Jenkins server.
Commander - Second and more customizable option is using the Commander add on for teams, which in addition to builtin commands provides the ability to Create your own Custom Commands.
With both options you will be able to tigger Jenkins jobs via the Remote Access API, see the This Question for additional info on remote execution.
I have a series of jenkins pipeline jobs to move Apps to Cloud Foundry. My client application need to be able to listen to all the updates of a push. I.e. apart from getting text logs, i need other events like Git repo cloned, cloud foundry logged in, App pushed.
One crud way of doing this is to submit POST requests to an event server from a shell script(Curl). However, I think it is unlikely that such a functionality does not exist already on Jenkins(either through a plugin or something like that).
I need an advice from best practices point of view.
Thanks.
As commented by mdabdullah. But this needs a person to set up kibana or splunk. (I did not try this).
Statistics gatherer plugin
https://plugins.jenkins.io/statistics-gatherer/
Jenkins notification plugin
https://plugins.jenkins.io/notification/
Both 2,3 are available plugins in the Jenkins community. They need to configured for server endpoints before use.
I'm having a team in BitBucket which has around 200+ members & 500 repositories. I wanted do some auditing of all repos & using BitBucket API for most of my work. I came across a requirement where I need to find out Admin members of each repos ( even one repo at a time will do), I read documentation but didn't find anything useful.
Can someone could guide me on this.
Thanks,
Meghanand
There's this rest api defined to get the users of a repository with their permissions in the below link for BitBucket stash.
/rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/permissions/users.
May be this can be extended to BitBucket Cloud.
https://docs.atlassian.com/DAC/rest/stash/3.11.3/stash-rest.html#idp494288
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.