Detect "existing" state of commits in a Bitbucket Pull Request even if the commits only exist in the fork (source repo)

Avatar
Gabor Nagy
Follow

Scenario:

  • There are two repos: "main" and "fork"
  • Policies are enabled on both (but policies might be different)
  • Developer pushes changes to "fork" (gets verified), then creates a PR to "main"
  • PR detects all commits as non-existing (and thus as to-be-verified) because they in fact do not exist in "main", just in "fork"
  • In reality, these commits are not necessarily need to be verified again when entering "main".

Problems: commits might be verified twice: in "fork" and in "main". But: if "fork" policy is less restrictive than "main" policy, the commits might be still needed to be verified.

Our current strict philosophy is to handle all commits "new" that do not yet exist in the repository that is being guarded. In the scenarios like explained above, we suggest relaxing the verification policy on "main" because the commits are already verified on "fork" some time, so they are safe to let in to "main".

Related ticket: #4566

Have more questions? Submit a request

1 Comments

Date Votes
  • 0
    Avatar
    George Ivanov

    The above proposal quite clearly states and explains the need for this. We'd only add/further clarify our use case for this feature to be implemented...

    1. Every dev team member usually creates a unique "fork" of the "main", where they push local changes to, before they get merged via a PR (both "fork" and "main" reside on a BitBucket server). That is done for a number of reasons: 1) To restrict/control what goes into mainline development; 2) To prevent "pollution" of "main" with branches and commits that aren't necessarily needed; 3) Track feature- and bugfix- development more easily;

    2. Due to the existing limitation of the add-on we are forced to have two sets of policies: one that applies to general-purpose commits (which is very strict) and another one that applies to merges only (very similar to the main one, but has relaxed rules to bypass the merge checks).

    3. We have also set BitBucket restrictions on the branches (i.e. “prevent all changes without a pull request”) that closes the loophole opened by the more relaxed “merge” commit policy described in the previous paragraph.

    4. Both policies are applied across all repositories we have (over 50), including all forks made (every single dev team member has a forked copy of the main repository where they commit/push their work before creating a pull request for this work to be merged into "main").

    So, for the above feature proposal to work, it needs to skip commits that have already been verified and exist not only in the destination repository ("main"), but all existing "forks" of "main".

    In addition, if the policy used in "main" differs from "fork", then the commits need to be verified (no skipping).

    One example of why that is needed is given in the feature proposal above: if there is less restrictive policy (or no policy at all) in use in "fork" compared to "main". The policy match could be done on policy ID.

    Edited by George Ivanov
Please sign in to leave a comment.