Level 65
Looks like some changes have been made and it won't pull unless they're stashed or commited.
You can do a hard pull (overwrite). Why has app.css been changed?
Feb 23, 2015
16
Level 55
Forge fails EVERY time
Forge fails every time when I deploy as it keeps asking me to commit my changes or reset them.
I am using Twitter Bootstrap - Sass and Elixir, along with Daniel Eden's Animate.css (Sass port).
When I automatically deploy, my migrations are run along with bower install and gulp (which I think is the issue)
But
How do I then get Laravel Forge to compile my latest CSS?
Here is the output from running git status via SSHing into Laravel Forge immediately after an automatic deployment.
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: public/css/app.css
modified: resources/assets/sass/animate/helpers/_settings.scss
no changes added to commit (use "git add" and/or "git commit -a")
Level 55
I has set my deploy script to run gulp as I mentioned above (which I think is causing the issue). Which if this is causing it, how else can I go about updating my css files?
Level 65
I run it on server as well and I actually exclude /public/assets/css and /public/assets/js since I compile it from bower_components via gulp.
If /public/css/app.css is in your git repo and you do gulp on server, it could well be different if you do --production to minify etc.
Level 55
public/css and public/js were in Git originally but I removed them early today so they shouldn't be affecting it now to my knowledge. Unless because they were there to begin with, I am now unable to remove them.
Level 65
Maybe do a hard pull then if they are now in .gitignore
git fetch --all
git reset --hard origin/master
Level 19
If this is your production server, it's surely not the way to be going about things.
The generally accepted workflow would be to use Bower and Gulp on your development server, which will publish your assets to the public folder.
After testing you would then push your changes to the production server (or even a staging server first), including the published assets.
Running Gulp etc. on the production server (live site) is asking for trouble.
Level 65
Yeah, I agree too. I tried both ways and found (for me) doing it on the server was easier and more fun :) working great in fact.
1 like
Level 55
@bashy which are you saying is better?
@sitesense I see where you are coming from, but then you could argue that you would also do the same for the vendor directory too.
Level 19
@bashy well I'm in no position to preach myself, I do it all the time lol, but it's not something I'd advocate. Things tend to go wrong at the worst moments I've found, mostly when rushing to get something done.
Level 19
@mstnorris the "vendor" directory?? How do you mean?
Level 55
@sitesense as in if I am not going to run gulp on the server then why would I run composer install?
Laravel Forge deploys automatically from GitHub and alike, and the vendor directory is ignored in Git so the dependencies have to be pulled in once deployed to the server.
Level 19
Well you've (hopefully) already run composer install in development and tested that everything works.
There is no real reason to have Bower, Gulp, the Node modules etc. on your production server at all. They're only there to publish the assets.
Regarding Forge and automatic deploy from Github, then why use Gulp on the server? There's nothing to gain?
You could end up with newer files on the live site than you have in development. As you've seen, you have already got problems with Github becoming out of sync.
Anyway, I'm not preaching... just an old boy offering some friendly advice, and of course all this only matters if your live site is critical to a business.
Level 55
@sitesense I am taking on board everything you're saying. It makes sense. I just assumed (wrongly by the sounds of things) that gulp, composer install, and bower install all do essentially the same thing.
I think I will re-jig my workflow tomorrow to accommodate for this.
Thank you.
Level 19
Well Bower is a package manager (like Composer) but for front-end stuff like javascript and css. It basically saves you the trouble of downloading JQuery, Bootstrap CSS etc.
Gulp is really just a tool to help you compile, minify and copy these assets to the right place (public folder).
After running Gulp in development, Git will notice the new files that are created and will know to push them with the next commit.
Your app itself has no knowledge or need of Bower or Gulp, just the files that are published. :)
Level 65
Yeah I wouldn't do gulp/bower on production server for anything important or if you haven't tested/know the consequences of it.
Level 2
Generated static files is something I don't keep in my Git repo. Because they are versioned, and it makes no sense to keep them there as developers who works on the project will always build their own static files from merged LESS, JS, etc.
So I find running Gulp on production is ok in that case. But it depends on project, of course. Production deployment lasts for 3 min in our case, and Gulp is only 20 sec of it.
Please or to participate in this conversation.