Taking a look

from dagu.

@zph Thank you very much for the thorough investigation! This is extremely helpful. I will take a look shortly.

from dagu.

To determine if it's related to #602 , I checked out the commit right before that PR's merge (fdcc93a):

test script (added second step in case this is about the ${})

params: commit=1
tags: fix🐞
steps:
  - name: step1
    command: bash
    script: |
      echo ${commit}
      export
  - name: step2
    command: bash
    script: |
      echo $commit $1
      export

The output of step 1 is:

"1"
.... (unrelated exported vars)
declare -x commit="\"1\""

Then I checked the tip of main (a20bd1d) and using same dag, I can reproduce your bug report:

<both the echo of commit is missing and the declare -x commit= are missing>

Then I run the commit where #602 was merged in (9ef8153)

The output is:

1
declare -x commit="1"

Summary

Pre #602 : it output commit=""1""
Immediately Post #602: it output commit="1"
Now: it doesn't output anything

In none of the cases does it explicitly 1="\"commit=123"

Finding

• commit=1 being exported regressed after #602 landed
• 1="commit=123" is not showing up before or after

Next Step

I'll git bisect to find where this changed after 602 landed.

from dagu.

Using git bisect:

git bisect start
git bisect good 9ef8153
git bisect bad a20bd1d
git bisect bad
git bisect good

I find the following:

e78459b is the first bad commit which looks like part of a large refactor.

from dagu.

@yohamta Can you please take a look since you know the code in the refactor?

from dagu.

The issue has been resolved in v1.14.2. Sorry for any inconvenience this may have caused. I greatly appreciate the support provided in helping to fix the problem. Thank you very much!

from dagu.