5.20.2

Changes

• Add conditions to check current branch by regex inspired by @Eydamos ;)
• Add On and NotOn branch conditions

The Condition\OnBranch condition is now deprecated and should be replaced with Condition\Branch\On.
Full list of Conditions can be found here

5.20.1

Changes

• Add IntegrateBeforePush action
• Add proper filter settings to not list deleted files
• Properly check the detected ranges
• Split debug action into Success and Failure

5.20.0

Changes

• Refactor and optimize changeset discovery huge thanks to @Eydamos
• Output executed cli command anyway in verbose mode
• Fix branch extraction
• Catch condition exceptions

🐛 Bugfixes

#233 #234

5.19.2

Changes

• Allow Symfony 7 - thanks to @alessandro-podo

5.19.1

Changes

This release focuses on cleaning up the installation and plugin confusion.
From this point forward the captainhook/composer-plugin is deprecated and "replaced" by captainhook/hook-installer.

The decision was made because the composer-plugin package was doing too much. And by requiring captainhook directly it did not give you the opportunity to choose the CaptainHook installation method yourself.

The new hook-installer package is only focusing on the functionality of activating the hooks for all your team members.
Especially because of an issue @Eydamos pointed out. The Composer "script" solution has some serious drawbacks when installing dependencies with --no-dev. You can follow the discussion over here.

From now on, to automate the hook activation, you should combine your preferred way of installing the Cap'n with requiring the hook-installer package.

Examples

Installing the Cap'n as PHAR via Composer

{
  "require-dev": {
    "captainhook/captainhook-phar": "^5.19",
    "captainhook/hook-installer": "^1.0"
  }  
}

Installing the Captain's source code and its dependencies with composer.

{
  "require-dev": {
    "captainhook/captainhook": "^5.19",
    "captainhook/hook-installer": "^1.0"
  }  
}

Installing the Cap'n via PHIVE and the hook-installer via composer.

{
  "require-dev": {
    "captainhook/hook-installer": "^1.0"
  },
  "extra": {
    "captainhook": {
      "exec": "tools/captainhook.phar"
    }
  }
}

5.19.0

Changes

• Increased PHP requirement to >= 8.0
• Overhauled the complete action output handling
• Add BlockSecrets action
• Improve export ignore
• Move some HookRunner logic to Config
• Remove php 7.4 build
• Remove unused import
• Cleanup hook argument handling

Issues Fixed

#28, #230

5.18.3

Changes

• Fix inject issue key action #230

5.18.2

Changes

• Fix commit issues on missing /dev/tty for Jetbrains IDE thanks to @hoogi91

5.18.1

Changes

• Fix PHAR build

5.18.0

Changes

• Improve run configuration fixes issue #178 big thanks to @renky
• Improve a bunch of types

If you use Docker to execute the captain until now you could run into problems by using git commit -a.
The reason being that git uses an environment variable to configure the index file to use.
The command git commit -a creates a new index file with everything in in it not changing your original index before the command succeeds.

So for this to work, the GIT_INDEX_FILE environment variable hat to be forwarded to the Docker container. And more, since the variable contains the path to the index file the path had to be mapped from the host system path to the container path.

This is now all done by the Capn, but only if you specify the run-gitconfig value with the path to the.git` directory within your container.

Here is an example configuration:

{
  "config": {
    "run": {
      "mode": "docker",
      "exec": "docker exec my-container",
      "path": "vendor/bin/captainhook",
      "git": "/docker/mx-project/.git"
    }
  }
  ...
}

For hooks that could need the environment variable like pre-commit this will result in Docker command like this:

docker exec -i -e GIT_INDEX_FILE=/docker/my-project/.git/($GIT_INDEX_FILE) my-container vendor/bin/captainhook ...

So from version 5.18.0 the Cap`n tries to optimize you docker commands. If you run in any problems let me know.