The current workflow requires actions/checkout@v4 to run before hand. This makes using iron-proxy incompatible with steps that don't use checkout. My use case is Python package publishing uses a multistep workflow, and the publish step does not use the checkout action and does not have egress-rules.yaml available. If you allowed inline egress rules, that would allow this usage to work.
Example allowing egress-rules to an object (in addition to a file path):
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: ironsh/iron-proxy-action@v1
with:
egress-rules:
domains:
- "registry.npmjs.org"
- "*.npmjs.org"
- "nodejs.org"
- "*.nodejs.org"
warn: 'true'
# ...
Or if having multiple types for a field is difficult/bad-practice, you could have a egress-rules-inline field that's mutually exclusive with egress-rules:
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: ironsh/iron-proxy-action@v1
with:
egress-rules-inline:
domains:
- "registry.npmjs.org"
- "*.npmjs.org"
- "nodejs.org"
- "*.nodejs.org"
warn: 'true'
# ...
The current workflow requires
actions/checkout@v4to run before hand. This makes using iron-proxy incompatible with steps that don't use checkout. My use case is Python package publishing uses a multistep workflow, and the publish step does not use the checkout action and does not haveegress-rules.yamlavailable. If you allowed inline egress rules, that would allow this usage to work.Example allowing
egress-rulesto an object (in addition to a file path):Or if having multiple types for a field is difficult/bad-practice, you could have a
egress-rules-inlinefield that's mutually exclusive withegress-rules: