Failed to ensure git is spawnable by backmerge process.

[syphernl]

It appears that problems of #17 have not been fully solved yet as there are still some cases where spawning Git appears to be problematic.

The verification is working:

[9:06:24 AM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@kilianpaquier/semantic-release-backmerge"
[9:06:24 AM] [semantic-release] [@kilianpaquier/semantic-release-backmerge] › ℹ  Using git version: 'git version 2.45.2'.
[9:06:24 AM] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@kilianpaquier/semantic-release-backmerge"

Semantic-release proceeds with analyzing the commits, executing a build of a Docker container (using brendangeck/semantic-release-kaniko), creating a GitLab release and then fails in the backmerge process again:

[9:10:31 AM] [semantic-release] › ℹ  Start step "success" of plugin "@kilianpaquier/semantic-release-backmerge"
[9:10:31 AM] [semantic-release] › ✘  Failed step "success" of plugin "@kilianpaquier/semantic-release-backmerge"
[9:10:31 AM] [semantic-release] › ℹ  Start step "fail" of plugin "@semantic-release/gitlab"
[9:10:33 AM] [semantic-release] [@semantic-release/gitlab] › ℹ  Commented on issue #xxxx: https://gitlab.com/[REDACTED]/-/issues/9.
[9:10:33 AM] [semantic-release] › ✔  Completed step "fail" of plugin "@semantic-release/gitlab"
[9:10:33 AM] [semantic-release] › ℹ  Start step "fail" of plugin "semantic-release-slack-bot"
[9:10:33 AM] [semantic-release] [semantic-release-slack-bot] › ℹ  Notifying on fail skipped
[9:10:33 AM] [semantic-release] › ✔  Completed step "fail" of plugin "semantic-release-slack-bot"
[9:10:33 AM] [semantic-release] › ✘  EGITSPAWN Failed to ensure git is spwanable by backmerge process.
Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'marked-terminal' imported from /usr/local/lib/node_modules/semantic-release/index.js
    at packageResolve (node:internal/modules/esm/resolve:854:9)
    at moduleResolve (node:internal/modules/esm/resolve:927:18)
    at defaultResolve (node:internal/modules/esm/resolve:1169:11)
    at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:542:12)
    at ModuleLoader.resolve (node:internal/modules/esm/loader:510:25)
    at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:239:38)
    at ModuleLoader.import (node:internal/modules/esm/loader:472:34)
    at defaultImportModuleDynamicallyForModule (node:internal/modules/esm/utils:214:31)
    at importModuleDynamicallyCallback (node:internal/modules/esm/utils:253:12)
    at terminalOutput (file:///usr/local/lib/node_modules/semantic-release/index.js:29:43) {
  code: 'ERR_MODULE_NOT_FOUND'
}

The issue it comments on contains the following:

### Failed to ensure git is spwanable by backmerge process.

N2: Command failed with ENOENT: git --version spawn git ENOENT

• semantic-release version: 24.2.0
• semantic-release-backmerge: 1.5.2

[kilianpaquier]

Whut ... VerifyConditions works the first time but not the second time in success call 😰 ?

[syphernl]

Whut ... VerifyConditions works the first time but not the second time in success call 😰 ?

To add to the weirdness: this appears to be related to the content of the Dockerfile of the project I am releasing 🤯 ..
On the original codebase it is failing (with the errors above), if I simplify the container by simply doing:

FROM nginxdemos/hello

The backmerge works fine.

If I put back my original content of the Dockerfile, the backmerge is failing again.

The semantic-release-kaniko plugin that builds and pushes the container isn't doing much besides generating arguments and running execa on /kaniko/executor.

[kilianpaquier]

Are you extending this Dockerfile ? https://github.com/brendangeck/semantic-release-kaniko/blob/main/Dockerfile

[syphernl]

Are you extending this Dockerfile ? https://github.com/brendangeck/semantic-release-kaniko/blob/main/Dockerfile

No, the Dockerfile we use for running semantic-release looks like this:

FROM node:20.18.0-alpine3.20

# renovate: datasource=github-releases depName=chartmuseum/helm-push
ENV HELMPUSH_VERSION=v0.10.4

# Copy Kaniko executor from the Kaniko image
COPY --chmod=0775 --from=gcr.io/kaniko-project/executor:v1.23.2-slim /kaniko/executor /kaniko/executor

# Install helm binary
COPY --chmod=0775 --from=alpine/helm:3.16.2 /usr/bin/helm /usr/bin/helm

# hadolint ignore=DL3018,SC2015
RUN apk add --update --no-cache jq git docker-cli && \
    helm plugin install https://github.com/chartmuseum/helm-push --version "${HELMPUSH_VERSION}" || true

# Install buildx plugin for Docker
# renovate: datasource=github-releases depName=docker/buildx
ENV BUILDX_VERSION=v0.17.1
ADD --chmod=775 https://github.com/docker/buildx/releases/download/${BUILDX_VERSION}/buildx-${BUILDX_VERSION}.linux-amd64 /root/.docker/cli-plugins/docker-buildx

WORKDIR /

# Copy over dependencies needed by npm
COPY package.json package-lock.json /

# Install semantic-release plugins listed in package.json
# hadolint ignore=SC2016,DL3016,SC2046
RUN jq -r '.dependencies | to_entries | map("\(.key)@\(.value)") | .[]' /package.json > /deps.txt && \
    npm install -g --unsafe-perm $(cat /deps.txt) && \
    rm -f /deps.txt /package.json /package-lock.json && \
    npm cache clean --force

WORKDIR /workspace

ENTRYPOINT [ "/usr/local/bin/semantic-release" ]
CMD ["--help"]

[syphernl]

I did some more debugging / testing.. Added in outputs of cwd and env, in both cases it is 100% the same so the Kaniko plugin (or Kaniko) has not modified either of these.

As a test I replaced brendangeck/semantic-release-kaniko with codedependant/semantic-release-docker in the Semantic-Release configuration and the backmerge worked fine with the original Dockerfile.

As the semanic-release-plugin only collect inputs (based on config + envs), generates arguments and executes /kaniko/executor with those arguments it is starting to look that Kaniko itself might doing something that causes this issue in this plugin.

[kilianpaquier]

Well, fine by me if the issue is coming from another plugin 😂

[syphernl]

Well, fine by me if the issue is coming from another plugin 😂

It appears to be that case, but can't explain yet as to why this is any why it would affect this plugin.

[syphernl]

It does indeed look like an issue caused by Kaniko. The first git --version runs and has 189 files in /usr/bin. The second run there are only 153, of which a few new ones that weren't in the first directory listing.
Seems that during the Kaniko build it overrides the files in the container Kaniko runs from.

This cannot be an issue of this plugin, so I'll close this issue.

[kilianpaquier]

Issue opened here brendangeck/semantic-release-kaniko#19 following investigation