.gitignore should be ignored for actions

[alanb-sony]

I'm trying to use the get-cmake action to download cmake. Strangely it has dist listed in its .gitignore so dist doesn't get copied into the docker container and the action fails.

[cplee]

Looks like it was removed, ok to close this issue now?

lukka/get-cmake#3

[alanb-sony]

The get-cmake action has been fixed but in general checking the git-ignore for actions is not necessary and could cause problems like this again in the future

[cplee]

Hey @alanb-sony - thanks for the PR! I need some help though understanding the scenario. Why wouldn't you want a .gitignore to be used within the action? I'm thinking of node_modules for example.

This seems like a bug with the cmake action in which there was a bad gitignore that needed to be fixed.

[alanb-sony]

doesn't act checkout a clean git copy of each action then copy the action to docker? There shouldn't be any uncommitted files in the host copy as it is never used for anything other than copying to docker?

[cplee]

It does...unless you are using a local action, stored in the same repo as your workflow with something like uses: ./.github/my-local-action

In that case, you would want any .gitignore to kick in to ensure you don't copy in files like node_modules

[cplee]

@alanb-sony - thoughts on comment above? still make sense to consider #198?

[alanb-sony]

I think some change is a good idea, don't know what though. I'm not a go expert (or even a novice)

[wagenet]

@cplee I think it would make sense to only respect .gitignore for local actions.

[marcaddeo]

This is also causing issues with actions/cache@v1 as it has dist/ in it's .gitignore

[cplee]

I like @wagenet idea - only use .gitignore for local actions

[github-actions]

Issue is stale and will be closed in 7 days unless there is new activity

[christopinka]

There seems to be a discrepancy between how Github runner behaves vs. an Act runner. I have a go project that is passing in Github and only passes in act if I delete the .gitignore. It leads me to believe that the Github runner is ignoring .gitignore and copying the files that go test can't find in Act unless I remove .gitignore. Should behave the same way.

[github-actions]

Issue is stale and will be closed in 7 days unless there is new activity

[wagenet]

Still should remain open.

[github-actions]

Issue is stale and will be closed in 14 days unless there is new activity

[wagenet]

There is a PR but it isn’t yet merged.

[github-actions]

Issue is stale and will be closed in 14 days unless there is new activity

[wagenet]

I think we still need this.

[jamesmortensen]

One of the use cases for using act to run workflows is to iterate and debug parts of them more quickly. If I want to fix a problem in the workflow, I don't necessarily need to do a fresh checkout of my codebase each time. Also, I can run workflows against uncommitted changes to decide whether or not I'm ready to commit. This allows me to move faster.

Some flag to be able to ignore the .gitignore would be awesome.

[miketalley]

I'm having an issue because .env is included in the .gitignore for the project. When running act the environment variables within .env are not getting loaded. Commenting out the .env line in .gitignore and running act seems to resolve the issue, but that means the .env would be committed to source control. ☹️

Having to change this each time that I run act is not great. A flag to ignore the .gitignore would be ideal and solve this issue.

[Totktonada]

My two coins regarding solution that would be ideal for me.

LT;DR: I would lean on git ls-files to create an include-list rather than on .gitignore to create an exclude-list.

The act tool is quite similar to packpack in the following aspect: both copy sources into a docker container and perform some work inside. Both assume that a developer's working tree may be not a clear copy, so just recursive copying is not the option.

The packpack tool runs git ls-files (for the repository and for its submodules) and creates a tarball with all listed files. The tarball is unpacked inside the container then. Untracked files will not go into the container, however gitignored files that are under git control will go.

Another nice property is that I can use git add to temporarily mark some new files as tracked and verify my build in a container.

My experience with this approach is great.