This fixes#499, where a matrix strategy with only include keys ends up
causing multiple builds. This bugs appears to have been introduced in #415,
when extra include keys are added in the matrix strategy. The cause
seems to be because the CartesianProduct function returns an item with
empty keys, instead of return an empty set.
Co-authored-by: Ed Tan <[email protected]>
If an action uses the branch to pin the major version, `- use: user/action@v1`
will stop with an error: "v1: reference not found."
In this case `act` should use refs/remotes/origin/v1 as a name to resolve v1 revision.
Co-authored-by: Casey Lee <[email protected]>
* Upgrade to the official golangci-lint action and fix some issues it found
* Update deps
* Remove a shadow warning
* Initialize the splitPattern only once
* Initial attempt at supporting $GITHUB_ENV
Needs some polishing and tests
* Now it's actually working
* Replace golang.org/x/crypto/ssh/terminal with golang.org/x/term
* Disable the issue-228 test again
* The linter is picky
* Discovered that the workflow/envs.txt had to exist in certain cases
* Fix small linter issue
* Pull latest changes from ref using cached repo
Act switched from checking out a branch to checking out
a hash in order to resolve#24 - see
bc5c23e8e4
This had a side effect of preventing `w.Pull()` from updating
to the latest commit if a ref was a branch/tag and the repo
already exists on disk.
This commit checks if input.Ref is equivalent to the resolved
hash, and runs `r.Fetch()` and checks out the branch for input.Ref
if it is different. `w.Pull()` can then pull the latest changes
before we checkout `*hash` again like normal
* Extract CloneIfRequired to reduce cyclomatic complexity
Co-authored-by: Casey Lee <[email protected]>
KADOTA, KyoheiandGitHub
Torbjørn VatnandGitHub
Josh SorefandGitHub
Máximo CuadrosandGitHub