I tested two different branches, it detects the changes after the push event and everything is fine
I have a branch (turkish รถ) that contains a special character. The push event trigger is working correctly. When I look at BitBucketPollLog No Change. However, I am making changes in the relevant branch.
Related
I have a project I have been working on, and I was suggested to use Gitbash and Bitbucket to keep track of all the changes I will make.
I made some changes, pushed them to my bitbucket, and then cloned it to really make sure I was working on the latest files. Made a few more changes on that cloned download, tried to run it on my hardware and it wouldn't run. Couldn't figure out why either.
I went back to the previous download and managed to get it running on my hardware setup. I have made a multitude of changes since but just completely forgot to push.
Now, when I try to push, because there are files I don't have locally, I get the error:
On branch master
Your branch and 'origin/master' have diverged, and you have 2 and 5 different commits respectively.
It also tells me to git pull to merge the remote to my local files.
I do not want to do that, as that would overwrite changes I want to keep locally. I just want to push what I have locally, to my remote.
I am not a software engineer at all. All of the helps pages and tutorials are going way over my head.
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.
I have previously use Jenkins and BitBucket on premises and been able to have Jenkins notify bitbucket of the build condition of each individual branch (success, failed, in progress) however since I moved to bitbucket cloud it has started applying the condition of every build on every branch to every branch. For example if I have just a master and develop branch (to keep it simple) and the master branch failed because of some deployment configuration I am unable to merge a fix into it from develop even if develop is passing because it claims 1 of my 2 builds is failing on the develop branch.
This is tough to explain clearly in words so I've attached some pictures:
Two branches one build failing but both being marked as failed
Showing that develop branch is passing
Proof it wont let me merge
These notifications come from jenkins and have been set up using the standard cloudbees-bitbucket-branch-source:2.9.7 plugin to scan my bit bucket cloud.
Okay so this was a really obvious mistake but I thought I would leave the reason why this happened here in case any one makes the same mistake. cloudbees-bitbucket-branch-source:2.9.7 notifies bitbucket using the commit ID, when creating the branch structure for the repository I branched off main to make develop and both got built but both had the same commit ID and so both were notified of both builds. The problem fixes it's self on the first cycle of code to run through it.
I'm setting up a new Jenkins job using multibranch pipeline and I have noticed that when a branch is deleted, it only has a strikethrough and isn't actually removed on Jenkins. This is solved by re-running branch indexing. However, I cannot really use this as it will also cause every other branch to rebuild (a consequence of how the repository is updated). Is there some custom code or pipeline/script I can run to re-index without building?
I've already looked at various UI methods such as suppressing SCM triggers, but this also negates push events from Github which is something we want to use.
The deleted/merged branch build will disappear after a period of time (<24 hours). It is not removed immediately to show the recently deleted/merged branches and give a chance to review the prior build statuses. It is relatively harmless since the jobs for these branches are deactivated (read-only).
Note that the removal is based on the branch indexing job running at regular interval, so if you have this disabled, it probably won't do it (not sure the SCM webhook calls are enough).
We're using Gerrit. We thought we could do the following:
create some commits on a topic branch:
- a
- b
- c
Push those commits to gerrit.
Get some reviews.
Have Jenkins build only the last commit of the bunch.
Unfortunately, it looks like gerrit internally creates three different branches for those three commits, and when we have Jenkins run the script to build the topic, it winds up picking a different commit than the one we intended. Is there someway to get the behavior we desire?
You can change the project configuration to only create one review for your series of changes. This can be done by setting the Create a new change for every commit not in the target branch to false
Biggest disadvantage is that you can't review what has been changed in the changesets leading up to the latest change.
See the Gerrit Documentation
Gerrit always creates one change (review) for each commit pushed. There's no way to create one unique change for a bunch of commits. Commits are stored in special branches (like, for example, refs/changes/12/40312/1) until they aren't submitted (merged in the final branch).
You can, of course, build several commits at once after they are submitted to the branch but you only can trigger Jenkins to start a build every time some commit is merged in the branch (one build for each commit). If you want to have just one build for a bunch of commits you could consider to make scheduled builds started automatically some time of the day (night builds).