Feature/unique container names#6062
Open
drivera73 wants to merge 13 commits into
Open
Conversation
When running two instances of act against the same Docker environment, the container naming code produces consistent, repeatable names every time - even if the user isn't interested in reusing the build containers. As a result, these act instances will interfere with each other and this will result in odd errors and failures. The solution is to introduce a random string to the container name such that all containers created and managed by a specific instance of act will be distinct from those managed by other instances. In addition, if the --reuse option is in play, this behavior is disabled and the old, repeatable naming approach (albeit with a slight tweak to the name :) ) will come into play again.
This covers the case of someone using the act code as a library (???), and avoids them running into the same issues under that scenario.
The parameter now describes what it does and why ... --parallel implied other things
Some NodeJS actions can trip up if this isn't done properly
|
Hi ...is there any hope of getting this merged into the mainline? |
kjelly
added a commit
to kjelly/act
that referenced
this pull request
Jun 2, 2026
…nd fixes Features: - Add git worktree support for container mounts (nektos#6075) - Add --unique-container-names flag for parallel act instances (nektos#6062) - Add workflow_call inputs test coverage Fixes: - Resolve Dockerfile context from action.yml location (nektos#6085, nektos#6087) - Remove unsafe exec() in action.go (nektos#6082) - Tolerate unknown protobuf fields in artifacts v7 (nektos#6053) - Add mutex to LocalRepositoryCache (nektos#6055) - Prevent path escape in CopyTarStream (nektos#6093) - Send gh token only for correct hostname (nektos#6078) - Add deployment boolean and queue field to workflow schema (nektos#6097, nektos#6098) - Add artifact-metadata permission to schema (nektos#6069) - Clearer job status with emoji indicators (nektos#6080) - Use readlink for action canonical path (nektos#6068) Excluded: Dependabot dependency updates
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When running two instances of act against the same Docker environment, the container naming code produces consistent, repeatable names every time - even if the user isn't interested in reusing the build containers. As a result, these act instances will interfere with each other and this will result in odd errors and failures. The solution is to introduce a random string to the container name such that all containers created and managed by a specific instance of act will be distinct from those managed by other instances.
In addition, if the --reuse option is in play, this behavior is disabled and the old, repeatable naming approach (albeit with a slight tweak to the name :) ) will come into play again.
An explanation of the use case and the issues can be found here.