Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.foreverignore file not working for sub directories with -w #235

Closed
moneal opened this issue Jan 24, 2012 · 47 comments

Comments

Projects
None yet
@moneal
Copy link

commented Jan 24, 2012

Normal ignore rules don't seem to work correctly with forever. I was trying to add my .git folder and was unable to get it working. I tried with the below file.

.git
.git/
.git/*

The first line is the only one that should be needed.

If you did a git pull and a file changed in the .git folder forever would restart.

info:   restaring script because /mnt/home/test/.git/FETCH_HEAD changed
warn: Forever detected script exited with code: null
warn: Forever restarting script for 1 time
@mhart

This comment has been minimized.

Copy link

commented Feb 6, 2012

I'm seeing the same issue. Also tried:

.git/**/*

To no avail.

@dimsmol

This comment has been minimized.

Copy link

commented Feb 7, 2012

It's a bug in plugins/watch.js

watchFilter() calls minimatch this way:

minimatch(fileName, this.watchIgnorePatterns[key], { matchBase: this.watchDirectory })

But minimatch doesn't use matchBase as a base path, it's a boolean argument.
So minimatch matches pattern against full file path.

You can workaround it for now, using

**/.git/**

But this should be fixed, surely.

@moneal

This comment has been minimized.

Copy link
Author

commented Feb 9, 2012

I can confirm that **/.git/** works for .git folders.

@jcayzac

This comment has been minimized.

Copy link

commented Feb 20, 2012

Where do you put that file, exactly? I tried in the current directory, in the script's directory, and in ~/.forever/. Nothing worked.

kof added a commit to skimcom/forever that referenced this issue May 4, 2012

closes foreversd#164 and foreversd#235 fix wrong usage of matchBase o…
…ption of minimatch, use relative to watchDirectory path fore matching
@kof

This comment has been minimized.

Copy link
Contributor

commented May 4, 2012

AvianFlu added a commit that referenced this issue May 4, 2012

closes #164 and #235 fix wrong usage of matchBase option of minimatch…
…, use relative to watchDirectory path fore matching

@AvianFlu AvianFlu closed this May 6, 2012

@fent

This comment has been minimized.

Copy link

commented May 8, 2012

So how should we be using this now? **/.git/** nor .git work. The script still restarts.

@mikermcneil

This comment has been minimized.

Copy link

commented May 14, 2012

Verified-- doesn't work for me either. Tried:

.git
.git/**/*
**/.git/**/*

@AvianFlu AvianFlu reopened this May 14, 2012

@AvianFlu

This comment has been minimized.

Copy link
Contributor

commented May 14, 2012

Reopened pending investigation. Was supposed to have been fixed by a PR - possibly not.

@kof

This comment has been minimized.

Copy link
Contributor

commented May 14, 2012

It is only partially fixed, because forever should use fstream-ignore module not just minimatch. Here is what @isaacs said if you don't read the link above:

Because when you .gitignore a folder, it doesn't even bother to traverse it at all.

You cannot get the .gitignore-style behavior by making a list of every file and then glob-matching each one. For starters, that's ludicrously expensive (you may have a .gitignore'd folder with 100000 files in it or something), and also, you have to keep track of whether the parent was ignored. However, it gets more complicated, because a rule might cause you to have to look for specific items, if they're un-ignored with a negated rule.

I wrote fstream-ignorefile specifically for this use case. If you find a situation where it fails to include/exclude a file that git would, then please let me know.

@sbabigian

This comment has been minimized.

Copy link

commented Aug 28, 2012

So what's the status of this issue? Does anyone have any documentation on how we should be using foreverignore now to ignore entire folders and their subfolders and files?

@Apsu

This comment has been minimized.

Copy link

commented Nov 11, 2012

There hasn't been an update in 3 months. What's the current status of this issue?

@hannesgassert

This comment has been minimized.

Copy link

commented Nov 14, 2012

+1

@nene

This comment has been minimized.

Copy link

commented Nov 15, 2012

I'd also express my support for fixing this.

Additionally there seems to be no documentation on using the .foreverignore file. The only thing seems to be the warning message that complains about the missing .foreverignore file.

Thanks to @dimsmol for a workaround.

@protometa

This comment has been minimized.

Copy link

commented Apr 21, 2013

Unlike git, I really only want forever to watch my server file and a few other supporting files. Would an inclusive .foreverwatch file be a possibility as opposed to the exclusive .foreverignore? Would it be easier to implement?

@danielmahon

This comment has been minimized.

Copy link

commented May 6, 2013

The work-around doesn't seem to be working anymore...

**/public/** doesnt work

@D1plo1d

This comment has been minimized.

Copy link

commented May 7, 2013

For anyone who stumbled upon this like me, the .foreverignore functionality seems to have moved to forever-monitor.

There is also a pull-request ( foreversd/forever-monitor#30 ) on forever-monitor which aims to fix this issue. No idea if it works or not though.

@talamaska

This comment has been minimized.

Copy link

commented May 27, 2013

I'm planning to use the forever module as pure cli tool, do I still need the forever-montor?

@tutley

This comment has been minimized.

Copy link

commented May 31, 2013

I tried to ignore this issue and keep using forever.... forever, but I just can't. Every time I save a view my entire app restarts. Time to use nodemon or something.

@diki

This comment has been minimized.

Copy link

commented Aug 18, 2013

I could not make forever to ignore files with .foreverignore. To overcome the problem ( and if you want to go on with forever) install forever-monitor then make this change abueckerMB/forever-monitor@9d80005
Finally start your process with forever-monitor. I found its usage straightforward just follow the steps on project page

@thatjuan

This comment has been minimized.

Copy link

commented Mar 9, 2014

+1

7 similar comments
@jpadilla

This comment has been minimized.

Copy link

commented Mar 17, 2014

+1

@Shahul3D

This comment has been minimized.

Copy link

commented Apr 12, 2014

+1

@Rakk4403

This comment has been minimized.

Copy link

commented May 16, 2014

+1

@denisu

This comment has been minimized.

Copy link

commented May 18, 2014

+1

@CleanUnicorn

This comment has been minimized.

Copy link

commented Jun 2, 2014

+1

@thechriswalker

This comment has been minimized.

Copy link

commented Jun 3, 2014

+1

@freewil

This comment has been minimized.

Copy link

commented Jun 26, 2014

👍

@freewil

This comment has been minimized.

Copy link

commented Jun 26, 2014

**/.git/** is working for me in .foreverignore with v0.11.1

@dburrows

This comment has been minimized.

Copy link

commented Jul 7, 2014

+1

1 similar comment
@ric03uec

This comment has been minimized.

Copy link

commented Jul 10, 2014

+1

@gadelkareem

This comment has been minimized.

Copy link

commented Nov 26, 2014

It looks like adding full path for script produces this issue. Workaround is changing directory first

cd /var/www/example.com/ && forever -w start app.js
@wyqydsyq

This comment has been minimized.

Copy link

commented Dec 4, 2014

Why has this still not been fixed? It's a pretty damn important component of forever as without being able to ignore files, the -w flag is completely useless in any scenario where files are generated (such as a cache) which you don't want to restart for each change.

@kevzettler

This comment has been minimized.

Copy link

commented Jan 2, 2015

If this is not going to be fixed at least remove it. Update the documentation, and point people to forever-monitor if thats the preferred solution.

indexzero added a commit to foreversd/forever-monitor that referenced this issue Jan 7, 2015

@indexzero

This comment has been minimized.

Copy link
Member

commented Jan 7, 2015

@kevzettler it will be fixed when there is time. I was able to do a quick spike on this tonight by adding a test case to forever-monitor in foreversd/forever-monitor@3af5ce7. This is not a minimatch issue since minimatch works fine in forever-monitor. We must somehow be passing bad config information to the forever-monitor instance.

If you'd like to contribute some time of your own it would be very welcome.

@dermidgen

This comment has been minimized.

Copy link

commented Jan 7, 2015

@indexzero - I don't see what is still borked here. Let's close this.

#235 (comment) - as well as foreversd/forever-monitor#30 which you already merged into forever-monitor ages ago appear to have resolved the issues.

See also #235 (comment)
All those +1 folks are mistaken and not paying attention. PR30 was merged in 2013.

@indexzero

This comment has been minimized.

Copy link
Member

commented Jan 7, 2015

Thanks @dermidgen. I'm going to leave this open until I have test coverage for it in forever, but I appreciate your time looking into this.

@dermidgen

This comment has been minimized.

Copy link

commented Jan 7, 2015

Roger that. I will happily join you in this effort. I see you've started with some test coverage in forever-monitor; I will start looking at forever

@indexzero indexzero referenced this issue Jul 24, 2015

Open

Test coverage to improve #738

0 of 2 tasks complete
@indexzero

This comment has been minimized.

Copy link
Member

commented Jul 24, 2015

Closing this in favor of tracking it on #738.

@daslicht

This comment has been minimized.

Copy link

commented Mar 23, 2016

Is there meanwhile any solution ?

@jeffmcmahan

This comment has been minimized.

Copy link

commented Nov 17, 2018

I love forever, and have used the CLI for many years in many projects. The developers deserve enormous credit.

Now, I'm using v0.15.3 and in my case, ignored subdirectories are being watched. This has been so for years, and I've come back to this thread a half dozen times over the past 4-5 years.

I think the following sums up the situation: (i) The maintainers seemed to regard the problem with the CLI as fixed before it worked the way the users above wanted. (ii) There's no test in place that covers the way the users above want the CLI to work.

The following demonstrates the the CLI does not respect .foreverignore subdirectories, exactly as OP described (paste into terminal):

# Create a project directory.
cd ~ && mkdir foo-project

# Create project files.
echo "require('http').createServer(r => {}).listen(3000)" > foo-project/index.js
mkdir foo-project/foo
mkdir foo-project/foo/bar
echo "console.log('fizz');" > foo-project/foo/bar/index.js

# Add .foreverignore to tell forever to ignore foo.
echo "foo" > foo-project/.foreverignore

# Add a JSON conf file to tell forever to watch the project.
echo "{\"watch\":true,\"script\":\"index.js\"}" > foo-project/forever-conf.json

# Run the project.
cd foo-project && forever start forever-conf.json

$ forever list will show a running process. Now we'll change a file that lives in foo/bar (paste into terminal):

cd ../
echo "console.log('buzz');" >> foo-project/foo/bar/index.js

The process should not have restarted, but the log file will indicate that it did so:

error: restarting script because add changed
error: Forever detected script was killed by signal: SIGKILL
error: Script restart attempt #1

If I'm doing something wrong here, please indicate how I should change what I'm doing; I'll be grateful.

@wyqydsyq

This comment has been minimized.

Copy link

commented Nov 21, 2018

@jeffmcmahan the solution is to use PM2 or nodemon. Forever hasn't had any commits to master in over 2 years, it seems quite clear it's a dead project.

Nodemon is almost identical to forever in features, except their watch/ignore actually works as documented.

@jeffmcmahan

This comment has been minimized.

Copy link

commented Nov 21, 2018

Not sure how I failed to notice that. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.