act
act copied to clipboard
fix: accept platforms name contained equal sigh
Fix #2159 I hope to help act user using GitHub EnterPrise Server.
Codecov Report
Attention: 893 lines
in your changes are missing coverage. Please review.
Comparison is base (
4989f44
) 61.22% compared to head (157b0be
) 60.78%. Report is 303 commits behind head on master.
Additional details and impacted files
@@ Coverage Diff @@
## master #2160 +/- ##
==========================================
- Coverage 61.22% 60.78% -0.44%
==========================================
Files 46 53 +7
Lines 7141 8966 +1825
==========================================
+ Hits 4372 5450 +1078
- Misses 2462 3079 +617
- Partials 307 437 +130
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@wolfogre Thank you for checking As you may know, GHE users can't pick the GH Managed runner service so, we necessarily use self-hosted-runner when using GH Actions.
In my case, I use self-hosted-runners that are labeled the name IMAGE=debian-12
at my organization.
however, I can't use act in my workspace using GHE because of this issue. And I don't hope to modify the runner-label for using this tool.
runner-label 's specification accepts =
so if act support self-hosted-runner platform, may need this change.
thanks.
Sorry, I'm afraid I need to reserve my opinion. I don't see a strong reason to include =
in the label name in your case.
For most command tools, a=b=c
will be treated as a: b=c
, like docker run --env a=b=c --label a=b=c
. And act has many parameters with key-value format. I hope they could keep the same behavior to avoid confusion.
$ act -h | grep stringArray
--container-cap-add stringArray kernel capabilities to add to the workflow containers (e.g. --container-cap-add SYS_PTRACE)
--container-cap-drop stringArray kernel capabilities to remove from the workflow containers (e.g. --container-cap-drop SYS_PTRACE)
--env stringArray env to make available to actions with optional value (e.g. --env myenv=foo or --env myenv)
--input stringArray action input to make available to actions (e.g. --input myinput=foo)
--matrix stringArray specify which matrix configuration to include (e.g. --matrix java:13
-P, --platform stringArray custom image to use per platform (e.g. -P ubuntu-18.04=nektos/act-environments-ubuntu:18.04)
--replace-ghe-action-with-github-com stringArray If you are using GitHub Enterprise Server and allow specified actions from GitHub (github.com), you can set actions on this. (e.g. --replace-ghe-action-with-github-com =github/super-linter)
-s, --secret stringArray secret to make available to actions with optional value (e.g. -s mysecret=foo or -s mysecret)
--var stringArray variable to make available to actions with optional value (e.g. --var myvar=foo or --var myvar)
imo yaml config files really make sense, the cli usage is super complex and .actrc is not a good format.
I believe the following yaml, make all escaping rules pretty clear.
platforms:
["ubuntu-latest", "self-hosted"]: "test"
@wolfogre
I agree with your thoughts, but how should I interpret the message here, which is also mentioned in #2159 ?
It seems to accept a=b: c
.
[test workflow/demo] 🚧 Skipping unsupported platform -- Try running with `-P IMAGE=debian-12=...
I would like to avoid changing the runner-label name to use act if possible. This is a so useful tool, but when using GH Actions, I don't hope should not be forced to use label names that take into account the specifications of this tool .
How about modifying the content to accept the format of grouping the key string with any symbols. Would it look ugly? 'a=b'=c
I don't have a strong opinion against this change, but this change is blocked for now until the requested changes are resolved.
We also need to make ,
a separator of the key, to correctly map multi label self-hosted runner constructs in nektos/act.
Then obviosly the question comes up, what if my autoscaler embeds a ,
into a single label
Gitea hacked something together to workaround the multi label bug of act, but only one single label definitions wins while multiple images are possible for them as of now.
'a=b'=c
What would we do about a currently valid label char like '
? It's about as exotic as a =
sign in a label.
Before you opened the issue, I didn't even know that =
are used in GitHub Actions Auto scalers. Without autoscalers this label syntax doesn't make sense for me.
wolfogre
working on Gitea Actions, might be in a different world due to autoscalers not beeing that common there yet. I believe that pure dynamic labels don't work in gitea unless the autoscaler has a list of all possible images in the label IMAGE=<image>
construct.
It might be not be that easy to make a technical discussion together with act maintainers, I tried it once and it was pretty silent
@wolfogre Please re-review.
@wolfogre Please re-review.
I take a neutral stance on this. Please ignore my change request and let other maintainers decide.