Limit trigger per bundle

I thought this would be useful as well!
Here is a patch that I am using to accomplish this.

You should now be able to choose individual bundles in the build hooks settings page.

1. +++ b/config/install/build_hooks.settings.yml
   @@ -1,3 +1,6 @@
   +  entity_bundles:
   +    node: {  }
   

   we need a corresponding change in the schema.yml file too

2. +++ b/src/DeployLogger.php
   @@ -64,11 +64,21 @@ class DeployLogger {
   +  public function isEntityLoggable(ContentEntityInterface $entity) {
   

   the change in function name here is a BC break - instead could we add an additional method and check isEntityTypeLoggable && isEntityLoggable?

3. +++ b/src/DeployLogger.php
   @@ -64,11 +64,21 @@ class DeployLogger {
   +    // Check if the Entity Bundle is enabled.
   +    $selected_entity_bundles = $this->configFactory->get('build_hooks.settings')
   +      ->get('logging.entity_bundles.' . $entity->getEntityTypeId());
   

   this would require people to update their config, we should make it that 'no bundles selected == all bundles' so that there's no BC issues

4. +++ b/src/Form/SettingsForm.php
   @@ -13,20 +15,35 @@ use Symfony\Component\DependencyInjection\ContainerInterface;
   -  public function __construct(
   -    EntityTypeManagerInterface $entityTypeManager
   -  ) {
   

   the module is stable, so this is a BC break - we should use BC here as follows:

   * allow the new argument to be null
   * if it is null trigger a deprecated error and use the \Drupal singleton to set the value

5. +++ b/src/Form/SettingsForm.php
   @@ -59,15 +78,40 @@ class SettingsForm extends ConfigFormBase {
   +        '#title' => $form['logged_entity_types']['#options'][$entity_type] . ' Bundles',
   

   this can't be translated

6. +++ b/src/Form/SettingsForm.php
   @@ -76,9 +120,22 @@ class SettingsForm extends ConfigFormBase {
   +        $config->set('logging.entity_bundles.' . $entity_type, $form_state->getValue($entity_type . ':enabled_bundles'));
   

   this fails to remove bundles of entity types that were previously enabled but are now disabled

@larowlan,

Thanks for the thorough review! Will be updating the patch with hopefully all of these items addressed

Updated patch to work with latest release.
Addressed item mentioned.

1. schema.yml changes made
2. Keeping isEntityTypeLoggable() as recommended. isEntityLoggable() is just a new function.
3. Fixed!
4. Great idea. Fixed!
5. I think the label is already translated so just manually translated the last 'Bundles' txt.
6. Fixed!

Please follow up if you find anything else.

I missed a !.
Re-running tests.

Thanks for this.

We now need an upgrade path and a test to go with that.

The tests are failing because the default value assumes the node module is enabled, we'll need to set it to be empty by default

Not to take away from the great work done on this issues, but I would find this more useful if the bundles were associated with each of the build hooks. The use case is that I have one Drupal instance that serves multiple sites.

For example:
- Developer blog (prod) would have "Developer blog page", "Developer blog entry", and "Developer blog author" content types associated with it
- Developer blog (stage) would have the same as above
- Virtual event (prod) would have "Virtual event page", "Virtual event speaker", and "Virtual event agenda session" content types associated with it
- Virtual event (stage) would have the same as above

If it's out of the scope of this issue, I might open a new issue and begin work on something like this, but I think that both implementations in the same module would be redundant