RFE: support substitution in environment.environment in nested pipelines or actions #1402
Comments
smoser
added a commit
to smoser/wolfi-os
that referenced
this issue
Oct 8, 2024
A couple things here:
1. fix FTBFS state that apache-arrow was currently in.
* need zstd-static because:
CMake Error at /usr/lib64/cmake/zstd/zstdTargets.cmake:107 (message):
The imported target "zstd::libzstd_static" references the file
"/usr/lib/libzstd.a" uses=cmake/configure
but this file does not exist. Possible reasons include:
2. cherry-pick a patch (from 2016) to rapidjson that allows a user of it
(apache-arrow) to build with gcc-14.
3. Add environment variables to build so the python build modules
have access. I had hoped to localize these or use substitution
in the environment block, but that is not supported.
chainguard-dev/melange#1548
chainguard-dev/melange#1402
4. drop unnecessary runtime dependency from libarrow to libarrow.
5. remove pyarrow.
6. bump the epoch on apache-arrow to 3 to be newer than pyarrow was.
smoser
added a commit
to smoser/wolfi-os
that referenced
this issue
Oct 8, 2024
A couple things here:
1. fix FTBFS state that apache-arrow was currently in.
* need zstd-static because:
CMake Error at /usr/lib64/cmake/zstd/zstdTargets.cmake:107 (message):
The imported target "zstd::libzstd_static" references the file
"/usr/lib/libzstd.a" uses=cmake/configure
but this file does not exist. Possible reasons include:
2. cherry-pick a patch (from 2016) to rapidjson that allows a user of it
(apache-arrow) to build with gcc-14.
3. Add environment variables to build so the python build modules
have access. I had hoped to localize these or use substitution
in the environment block, but that is not supported.
chainguard-dev/melange#1548
chainguard-dev/melange#1402
4. drop unnecessary runtime dependency from libarrow to libarrow.
5. remove pyarrow.
6. bump the epoch on apache-arrow to 3 to be newer than pyarrow was.
smoser
added a commit
to smoser/wolfi-os
that referenced
this issue
Oct 8, 2024
A couple things here:
1. fix FTBFS state that apache-arrow was currently in.
* need zstd-static because:
CMake Error at /usr/lib64/cmake/zstd/zstdTargets.cmake:107 (message):
The imported target "zstd::libzstd_static" references the file
"/usr/lib/libzstd.a" uses=cmake/configure
but this file does not exist. Possible reasons include:
2. cherry-pick a patch (from 2016) to rapidjson that allows a user of it
(apache-arrow) to build with gcc-14.
3. Add environment variables to build so the python build modules
have access. I had hoped to localize these or use substitution
in the environment block, but that is not supported.
chainguard-dev/melange#1548
chainguard-dev/melange#1402
4. drop unnecessary runtime dependency from libarrow to libarrow.
5. remove pyarrow.
6. bump the epoch on apache-arrow to 3 to be newer than pyarrow was.
smoser
added a commit
to wolfi-dev/os
that referenced
this issue
Oct 8, 2024
…30285) A couple things here: 1. fix FTBFS state that apache-arrow was currently in. * need zstd-static because: CMake Error at /usr/lib64/cmake/zstd/zstdTargets.cmake:107 (message): The imported target "zstd::libzstd_static" references the file "/usr/lib/libzstd.a" uses=cmake/configure but this file does not exist. Possible reasons include: 2. cherry-pick a patch (from 2016) to rapidjson that allows a user of it (apache-arrow) to build with gcc-14. 3. Add environment variables to build so the python build modules have access. I had hoped to localize these or use substitution in the environment block, but that is not supported. chainguard-dev/melange#1548 chainguard-dev/melange#1402 4. drop unnecessary runtime dependency from libarrow to libarrow. 5. remove pyarrow. 6. bump the epoch on apache-arrow to 3 to be newer than pyarrow was. 7. provide multiple versions of the python modules, and make them provide 'pyarrow' for backwards compat.
gdonval
pushed a commit
to gdonval/wolfi-os
that referenced
this issue
Oct 9, 2024
…olfi-dev#30285) A couple things here: 1. fix FTBFS state that apache-arrow was currently in. * need zstd-static because: CMake Error at /usr/lib64/cmake/zstd/zstdTargets.cmake:107 (message): The imported target "zstd::libzstd_static" references the file "/usr/lib/libzstd.a" uses=cmake/configure but this file does not exist. Possible reasons include: 2. cherry-pick a patch (from 2016) to rapidjson that allows a user of it (apache-arrow) to build with gcc-14. 3. Add environment variables to build so the python build modules have access. I had hoped to localize these or use substitution in the environment block, but that is not supported. chainguard-dev/melange#1548 chainguard-dev/melange#1402 4. drop unnecessary runtime dependency from libarrow to libarrow. 5. remove pyarrow. 6. bump the epoch on apache-arrow to 3 to be newer than pyarrow was. 7. provide multiple versions of the python modules, and make them provide 'pyarrow' for backwards compat.
|
I think that generally it does work. I'm not sure what I was seeing when I opened this, but I suspect that it was related to nested pipelines. Here is an example to play with: package:
name: test-me
version: 1.0
epoch: 0
vars:
WARK: abc
FOO: boo
environment:
contents:
packages:
- busybox
environment:
BAR: "the other day I saw a BAR"
WARK: ${{vars.WARK}}
FOOFOO: "${{vars.FOO}} this should work too"
pipeline:
- environment:
XX: SuperX
runs: |
echo "did it work here? XX=$XX"
- environment:
XX: SuperX
uses: test/dump-env
with:
non-empty: BAR WARK FOOFOO XX
- environment:
MYVAR: "WINNER WINNER"
pipeline:
- runs: |
echo "==== FOO=$FOO ==="
echo "==== FOOFOO=$FOOFOO ==="
echo "==== BAR=$BAR ==="
echo "==== WARK=$WARK ==="
echo "==== MYVAR=$MYVAR ==="
- uses: test/dump-env
environment:
XX: SuperX
with:
non-empty: BAR WARK FOOFOO XX MYVARpipelines/test/dump-env.yaml: name: dump your environment
inputs:
non-empty:
required: true
pipeline:
- name: "test-non-empty"
runs: |
_fails=0
for n in ${{inputs.non-empty}} ; do
eval v='$'"${n}"
[ -n "$v" ] && echo "PASS: non-empty $n=$v" && continue
echo "FAIL: empty $n"
_fails=$((_fails+1))
done
exit $_fails
- name: "show env"
runs: |
envhere is the relevant output of |
smoser
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have a situation where I would like to put
SETUPTOOLS_SCM_PRETEND_VERSION=${{package.version}}into the build environment.I want to do:
The second 'OTHER' there i just put there. I think it is reasonable to support substitution within a string rather than only supporting the entire string. but I do not want to request shell-like behavior or expansion.
I also would lke to request that work within a 'range' section like seen here.
The text was updated successfully, but these errors were encountered: