What steps to follow when an add-on's repo starts to fail testing without any local changes

[apotek]

Hello, I have an add-on at https://github.com/ChromaticHQ/ddev-dblog/. Three days ago, it's test began to fail.

Leaving alone the bizarre fact that stable passes but HEAD doesn't even though they are identical, in the HEAD test output, there is no indication of the failure point. Everything looks fine until

not ok 1 install from release
# (in test file tests/test.bats, line 71)
# `ddev get chromatichq/ddev-dblog' failed

More context...

Bash completion has been installed to:
  /home/linuxbrew/.linuxbrew/etc/bash_completion.d
Run ddev debug download-images >/dev/null
  ddev debug download-images >/dev/null
  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
  env:
    HOMEBREW_NO_INSTALL_FROM_API: 
Run cd ./ && bats tests
  cd ./ && bats tests
  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
  env:
    HOMEBREW_NO_INSTALL_FROM_API: 
    DDEV_GITHUB_TOKEN: ***
    DDEV_NONINTERACTIVE: true
    DDEV_NO_INSTRUMENTATION: true
1..3
# ddev get chromatichq/ddev-dblog with project ddev-dblog in /home/runner/tmp/test-ddev-dblog (/home/runner/tmp/test-ddev-dblog)
not ok 1 install from release
# (in test file tests/test.bats, line 71)
#   `ddev get chromatichq/ddev-dblog' failed
# Creating a new DDEV project config in the current directory (/home/runner/tmp/test-ddev-dblog)
# Once completed, your configuration will be written to /home/runner/tmp/test-ddev-dblog/.ddev/config.yaml
# 
# Configuring a 'php' project named 'ddev-dblog' with docroot '' at '/home/runner/tmp/test-ddev-dblog'.
# For full details use 'ddev describe'.
# Configuration complete. You may now run 'ddev start'.
# ssh-agent container is running: If you want to add authentication to the ssh-agent container, run 'ddev auth ssh' to enable your keys.
# Not trying to add hostnames because DDEV_NONINTERACTIVE=true
# .....Installing chromatichq/ddev-dblog:v1.0.0
# Downloading https://api.github.com/repos/ChromaticHQ/ddev-dblog/tarball/v1.0.0
# 
# Installing global components:
# 👍 commands/db/dblog
# 
# Executing post-install actions:
# chmod: cannot access '/home/runner/.ddev/commands/db/dblog': No such file or directory
# failed to change mode of '/home/runner/.ddev/commands/db/dblog' from 0000 (---------) to 0000 (---------)
# 
# 👎 
# Could not process post-install action (0) ''

When I run the same commands in my shell, I am able to download/add the add-on just fine.

My guess is that maybe the test have changed and I need to update them? I am looking for docs on how to diagnose and fix failing add-on tests... What steps should I take?

Thank you.

[rfay]

What's going on (I think) is that in the latest (2) commits in DDEV HEAD the XDG_CONFIG_HOME environment variable is supported, and Github actions has XDG_CONFIG_HOME set. That means that DDEV is going to try to put the dblog command into ~/.config/ddev/commands/db/dblog. It's doing that... but then your post-install action is trying to find it at the ~/.ddev location.

So the HEAD tests did what they want to do and told us when something is failing...

However...

• Please remove the chmod, as it's not necessary anyway, DDEV does that for you. Or check it in with executable.
• You don't need the removal_action, because DDEV will remove things that you installed with your install.yaml.

So removing those two will solve this.

However, I'm going to convert this to an issue for now because this general problem may affect other add-ons that make assumptions about where the global DDEV config dir lives.

[rfay]

Followups in

• Add-on is installing global custom command, but it can't be accessed (with DDEV HEAD) at ~/.ddev/commands #6252