[GH-ISSUE #193] .gitignore should be ignored for actions #132

Closed
opened 2026-03-01 21:40:29 +03:00 by kerem · 21 comments
Owner

Originally created by @alanb-sony on GitHub (Apr 14, 2020).
Original GitHub issue: https://github.com/nektos/act/issues/193

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.

Originally created by @alanb-sony on GitHub (Apr 14, 2020). Original GitHub issue: https://github.com/nektos/act/issues/193 I'm trying to use the [get-cmake](https://github.com/lukka/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.
Author
Owner

@cplee commented on GitHub (Apr 16, 2020):

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

https://github.com/lukka/get-cmake/issues/3

<!-- gh-comment-id:614942798 --> @cplee commented on GitHub (Apr 16, 2020): Looks like it was removed, ok to close this issue now? https://github.com/lukka/get-cmake/issues/3
Author
Owner

@alanb-sony commented on GitHub (Apr 17, 2020):

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

<!-- gh-comment-id:615084667 --> @alanb-sony commented on GitHub (Apr 17, 2020): 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
Author
Owner

@cplee commented on GitHub (Apr 17, 2020):

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.

<!-- gh-comment-id:615262613 --> @cplee commented on GitHub (Apr 17, 2020): 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.
Author
Owner

@alanb-sony commented on GitHub (Apr 17, 2020):

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?

<!-- gh-comment-id:615263994 --> @alanb-sony commented on GitHub (Apr 17, 2020): 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?
Author
Owner

@cplee commented on GitHub (Apr 17, 2020):

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

<!-- gh-comment-id:615372134 --> @cplee commented on GitHub (Apr 17, 2020): 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`
Author
Owner

@cplee commented on GitHub (May 4, 2020):

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

<!-- gh-comment-id:623248969 --> @cplee commented on GitHub (May 4, 2020): @alanb-sony - thoughts on comment above? still make sense to consider #198?
Author
Owner

@alanb-sony commented on GitHub (May 4, 2020):

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

<!-- gh-comment-id:623307787 --> @alanb-sony commented on GitHub (May 4, 2020): I think some change is a good idea, don't know what though. I'm not a go expert (or even a novice)
Author
Owner

@wagenet commented on GitHub (May 7, 2020):

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

<!-- gh-comment-id:624955161 --> @wagenet commented on GitHub (May 7, 2020): @cplee I think it would make sense to only respect `.gitignore` for local actions.
Author
Owner

@marcaddeo commented on GitHub (May 10, 2020):

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

<!-- gh-comment-id:626382754 --> @marcaddeo commented on GitHub (May 10, 2020): This is also causing issues with `actions/cache@v1` as it has `dist/` in it's `.gitignore`
Author
Owner

@cplee commented on GitHub (May 13, 2020):

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

<!-- gh-comment-id:628275843 --> @cplee commented on GitHub (May 13, 2020): I like @wagenet idea - only use `.gitignore` for local actions
Author
Owner

@github-actions[bot] commented on GitHub (Jul 13, 2020):

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

<!-- gh-comment-id:657298324 --> @github-actions[bot] commented on GitHub (Jul 13, 2020): Issue is stale and will be closed in 7 days unless there is new activity
Author
Owner

@christopinka commented on GitHub (Sep 11, 2020):

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.

<!-- gh-comment-id:691186393 --> @christopinka commented on GitHub (Sep 11, 2020): 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.
Author
Owner

@github-actions[bot] commented on GitHub (Nov 11, 2020):

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

<!-- gh-comment-id:725045892 --> @github-actions[bot] commented on GitHub (Nov 11, 2020): Issue is stale and will be closed in 7 days unless there is new activity
Author
Owner

@wagenet commented on GitHub (Nov 12, 2020):

Still should remain open.

<!-- gh-comment-id:726111367 --> @wagenet commented on GitHub (Nov 12, 2020): Still should remain open.
Author
Owner

@github-actions[bot] commented on GitHub (Feb 19, 2021):

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

<!-- gh-comment-id:781725605 --> @github-actions[bot] commented on GitHub (Feb 19, 2021): Issue is stale and will be closed in 14 days unless there is new activity
Author
Owner

@wagenet commented on GitHub (Feb 23, 2021):

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

<!-- gh-comment-id:783847244 --> @wagenet commented on GitHub (Feb 23, 2021): There is a PR but it isn’t yet merged.
Author
Owner

@github-actions[bot] commented on GitHub (Mar 26, 2021):

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

<!-- gh-comment-id:807827923 --> @github-actions[bot] commented on GitHub (Mar 26, 2021): Issue is stale and will be closed in 14 days unless there is new activity
Author
Owner

@wagenet commented on GitHub (Mar 26, 2021):

I think we still need this.

<!-- gh-comment-id:808273167 --> @wagenet commented on GitHub (Mar 26, 2021): I think we still need this.
Author
Owner

@jamesmortensen commented on GitHub (Apr 10, 2021):

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.

<!-- gh-comment-id:817138720 --> @jamesmortensen commented on GitHub (Apr 10, 2021): 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.
Author
Owner

@miketalley commented on GitHub (Apr 12, 2021):

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.

<!-- gh-comment-id:817918406 --> @miketalley commented on GitHub (Apr 12, 2021): 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.
Author
Owner

@Totktonada commented on GitHub (Apr 19, 2021):

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.

<!-- gh-comment-id:822843647 --> @Totktonada commented on GitHub (Apr 19, 2021): 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](https://github.com/packpack/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](https://github.com/packpack/packpack/blob/0154f5e5af03126744e3ff35648de7264a011fcd/pack/tarball.mk#L26-L27) `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.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/act#132
No description provided.