I have a jekyll app that uses the jekyll-seo-tag. I forked jekyll-seo-tag to make some more tweaks. I pushed my changes up to Github and pointed my Gemfile to the forked repo.
When I run the app locally, I see the correct (i.e. new) behavior. When I push the jekyll app to Github, I see don't the updates.
I've inspected the Gemfile.lock file on Github and it's pointed to my forked repo and is using the correct SHA.
I tried to get Github to rebuild the page by sending an empty commit.
git commit -m 'rebuild site' --allow-empty
But it had no effect.
My guess is that when GitHub builds the app, it's using a cached version, but that's just a theory. I get no errors anywhere.
Any idea what else I can do to troubleshoot this?
Related
I'm fairly new to ruby and jekyll and I wanna start using jekyll to meu personal webpage. Among the files in my repo there is a'Gemfile' and 'Gemfile.lock' files.
The Gemfile is used to manage dependencis and Gemfile.lock is generated through
bundle install
Is any of them required to be in the repo, or does gh-pages overrides any definitions contained in those files?
Other contained folder is '.sass-cache'. From this question I get the impression that it's used for caching issues. Once again, is it required, or gh-pages generates those files itself?
You can version your Gemfile. This can be useful for a reinstall. gemfile.lock and .sass-cache are not necessary to push to Github. They are used locally.
If your Gemfile contains something other than:
source 'https://rubygems.org'
gem 'github-pages'
That certainly means that you use plugins that are not supported by Github (see supported plugins list here). You then need to generate your site locally and push the result to your Github.
I've described a workflow here and you can also have a look at Octopress rake file that can help for such a setup (need small hacks to be used on a basic Jekyll install).
From my interpretation of the docs, github simply uses their own github-pages gem to pull in dependencies and then runs jekyll serve on your repo.
One consequence of that is that your gemfile (and thus any gems not part of github-pages) is ignored. For example, I use jekyll-less to generate my CSS but since this is not part of github-pages, making CSS changes is a multi-step process for me:
Update .less files
Build
Copy compiled CSS out of _site
Commit .css changes
Push
Another consequence is that any run-time or build-time stuff you use is ignored by github, so your .sass-cache directory does not need to be added to the repo.
I am trying to release a podspec on Cocoapods. According to the documentation, I should be able to use pod spec create [NAME] followed by rake release to release the podspec. Everything seems to go fine until rake release tries to push to the Specs repo.
Adding the spec to the `master' repo
$ /opt/local/bin/git status --porcelain 2>&1
- [No change] IPQuickModal (0.1.2)
Pushing the `master' repo
Username for 'https://github.com': brightredchilli
Password for 'https://brightredchilli#github.com':
remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/CocoaPods/Specs.git/'
It looks like it is trying to push to the main Cocoapods Spec repo, which will make sense as to why it fails. Am I missing something? It looks like the tool is easy to use, but I need push access to the spec repo. However, this is not clear on the doc page.
To submit a podspec to CocoaPods (currently) you must submit a pull request to the specs repo. Currently no one but the core team has push access.
I was so excited to get a private CocoaPods repo working. I got v1.0 of my little internal library working with my main app like a charm. Then I added something to the library, committed it, tagged it with v1.1, pushed it up and everything went straight to hell.
No matter what I do, even though my main app reports that my internal library is pointed at 1.1, I keep getting the same code back as 1.0. I'm stumped.
Things I have verified:
My private pods repo has the correct folder structure, and the .podspec files in each folder have the appropriate s.version
Did a file compare of the two podspec files on my internal pods repo and confirmed that the only change to the file was the version number.
Did a git checkout tags/1.1 on the repo with the internal library and confirmed the 1.1 tag contains the appropriate commit.
Confirmed via the BitBucket website the file changes and tag for 1.1 made it there.
I have also tried the following things to resolve it (that I can remember right now) and still got the same code added in the Pod.
Removing the offending pod from the Podfile, running pod update to delete it, re-adding it, then running pod update again.
Clearing ~/Library/Caches/CocoaPods and [ProjectRoot]/Pods and running pod install.
Removing my remote pod repo via pod repo remove [NAME] and then re-adding it under a different name.
Pointing the podspec at :head
Pointing the podspec at the specific commit I wanted.
Pointing the podspec at my local copy of the library.
All this craziness points to some sort of caching issue with git or Xcode, but running CocoaPods in verbose mode doesn't seem to show anything other than super-temporary cache paths that get deleted the second pod update is done.
Anybody got any further suggestions? This is driving me bananas.
Update 1/24: I checked out the code under a seperate username and got some odd behavior:
pod install
Analyzing dependencies
Downloading dependencies
Installing [Private Library] (1.0)
Installing Google-Mobile-Ads-SDK (6.7.0)
Installing LARSAdController (3.0.3)
Installing UIAlertView-Blocks (0.0.1)
Generating Pods project
Integrating client project
[!] From now on use `[App Name].xcworkspace`.
Interesting, I thought, that it grabbed the 1.0 version even though I don't specify any version in the Podfile. So then I ran:
pod update
Analyzing dependencies
Downloading dependencies
Installing [Private Library] (1.1)
Using Google-Mobile-Ads-SDK (6.7.0)
Using LARSAdController (3.0.3)
Using UIAlertView-Blocks (0.0.1)
Generating Pods project
Integrating client project
And the code doesn't change, even though the version number increments. So this points to something I screwed up rather than a caching issue - but if I did, why the hell is it grabbing version 1.0 at all? Any thoughts?
Welp, this was a PEBKAC/not seeing the forest for the trees problem, which I realized when I tried to give up and switch to a git submodule and saw what appeared to be the same issue.
I'd pointed the CocoaPod at /[Project Root]/Library (and was initially looking in there when I tried to move to a git submodule), but when I'd dragged that folder into Xcode in the library project, I'd accidentally left the "Copy Items Into Destination Group's Folder (if needed)" checkbox checked. That created /[Project Root]/[Subfolder]/Library, where all of my changes were actually going. Once I fixed that, surprise surprise, everything worked fine.
So, uh, I guess the lesson here is that if you've gotten this far down the rabbit hole, step back and make sure there's even a rabbit you need to be chasing to begin with.
I have created one application using NodeJS, Angular and Express which I want to run at Heroku. Now, Im using Grunt to build the code that are placed in the dist folder and is ready to be deployed and run on Heroku. This would be done by pushing the dist folder in the Heroku git repo.
Now, should i push my source code in Heroku git as well?
If so, how should I seperate it from dist-folder repository? For instance, I dont want Heroku to run npm install each time i push changes to remote repo. And dist folder should not be part of the source code folder in the repository since it is auto generated.
Using a git repository is the only way to push changes to heroku. So yes it is mandatory. Having said that here is what they have to say about it.
Heroku provides the git service primarily for deployment, and the ability to clone from it is offered as a convenience. We strongly recommend you store your code in another git repository such as GitHub and treat that as canonical.
Again there is no way to stop them from doing an npm install on each push. Here is a quote from their getting started guide
Heroku recognizes an app as Node.js by the existence of a package.json. Even if your app has no dependencies, you should still create a package.json that declares a name, version, and empty dependencies in order that it appear as a Node app.
But I suppose that you could download all the dependencies of your app locally, not specify in package.json, push it along with rest of your application and you might trick heroku into thinking that there are no dependencies. Have not tried it myself though.
If you don't want dist folder to be a part of push simply gitignore it.
I've checked out my Ruby project from GIT and I've installed pow to run it on a friendly URL from my browser.
We've got a stable working version of our app running in our GIT 'master', but now I want to run our development branch on the same pow URL. I've already switched the working branch to our development branch 'redesign', but the Pow URL is complaining with error in the screen.
My question: Is it even possible to run POW on a directory using a GIT branch other than 'master'?
Yes, but you might need to restart pow to force it to refresh the code.
There's two ways to do this:
touch ~/.pow/restart.txt
Install the powder gem. That allows you to run powder restart on your app directory.
Also, you might want to run bundle on your project directory too, as dependencies might have changed in the new branch (hard to tell without more information.)