I am using GIT to deploy my cakephp applications, a few days ago I started using the migrations plugin (by cakeDC) in my app to simplify database versions and changes.
After installing the Migrations Plugin on my local development machine, I committed the changes and pushed it to my production server, and tried to run the migrations plugin from there.
After looking at the server for quite some time I realized it had not grabbed all of the migrations plugin, however the following were changed:
app/Config/bootstrap.php had the following line appended
CakePlugin::load('Migrations');
The Plugin folder now had a Migrations folder, but it was empty.
I resolved this by uploading the plugin via FTP. I ran a git status on it and it shows the working directory clean...
Why isnt GIT tracking my Migrations plugin folder contents?
The Plugin folder is not being tracked because GIT thought it was a submodule.
I ran into this issue because I used GIT to clone this Plugin into the plugin directory. and git didnt add it since it was a repository in itself. When GIT didnt add it to my tracked files I did it manually: git add app/Plugin/Migrations/
this created a gitlink and essentially acted like a submodule, as seen in this thread:
Git - how to track untracked content?
Since at the time I didnt want to use the plugin as a submodule, I corrected this issue with the following commands:
git rm --cached app/Plugin/Migrations
with a git status I could see that GIT was now recognizing my Plugin
I then could proceed with a git add . and git commit -m "finally adding the plugin"
I hope this helps someone in the future.
Thanks!
Related
Apologies, I am still a bit confused by git, although I am trying to teach myself more and improve.
I recently successfully deployed a React website to GitHub pages, following the often recommended steps of installing gh-pages to the project, adding a homepage property to the package.json file, adding scripts to the scripts properties on the package.json file, running 'npm run deploy' and so on. It worked fine, and now a build of the project has been added to my repository (here), and I can view the actual project online (here).
However, the issue I have is this: most guides on deploying a react app also mention the following steps:
in the terminal type:
git add .
git commit -m "commit"
git push origin master
These final steps are often listed as optional. Everything worked fine without me doing these steps: my code was added to the repository, and my website is deployed online, so what do these steps do exactly? Why are they considered optional? What is best practice?
These commands are not optional to me - when using only the command-line Git client, these commands accomplish the interaction of pushing the code (that, after you edit it, only exists locally on your own PC) to the Git repository server.
Everything worked fine without me doing these steps: my code was added to the repository, and my website is deployed online
I can see the following possibilities:
You are using another Git client and the push was done there;
You are using a Git tool (e.g. editing purely on the GitHub website), where the push happened without you being aware of it;
You did the terminal commands, without being aware of them;
A common resource to learn more about Git would be the Git book on the official Git SCM website: https://git-scm.com/book/en/v2
I have been trying out Codeship and Heroku for continuous deployment of an AngularJS application I writing at the moment. The app was created using Yeoman and uses bower and grunt. Initially I thought this seemed like a really good setup as Codeship was free to use and I was quickly able to configure this to build my AngularJS project and it offered the ability to add a deployment step after the build. There were even many PaaS providers to choose from (Heroku, S3, Google App Engine etc). However I seem to have become a bit stuck with getting the app to run on Heroku.
The problem started from the fact that all the documentation suggested that I remove the /dist path from my .gitignore so that this directory is published to Heroku post build. This was mainly from documentation that talked about publishing to Heroku from a local machine, but I figure this is all Codeship is doing under the hood anyway. I didn't want to do this as I don't believe I should be checking build output into source control. The /dist folder was added to .gitignore for a good reason. Furthermore, this kind of defeats the point of having a CI server somewhat, as I might as well just push the latest build from my machine.
After some more digging around I found out that I could add a postinstall step to my packages.json file such as bower install && grunt build which would re-run the build on Heroku and hence repopulate all the bower dependencies (something else they wanted me to check in to source control!) and the dist directory.
After giving this a try it became apparent that I would need to add bower and grunt as dependencies in packages.json, which meant moving them from devDependencies which is where they should belong!
So I now seem to be stuck. All I want to do is publish my build artefacts (/dist) the dependencies (/bower_components) and the server.js file that will run the site. Does anyone know how to achieve this with Heroku and Codeship? Alternatively has anyone had any success with this using different tools. I am looking for something that is free and I am willing to accept that it will not be production stable (won't scale to multiple servers etc), but this is fine for now as all I want to do is continuously deploy the app for internal testing and to be able to share the output with non-technical members of my team so we can discuss features we'd like to prioritise etc.
Any advice would be greatly appreciated.
Thanks
Ahoy, Marko from the Codeship crew here. Did you already send us an in app message about this? I'm sure we can get your application building on Codeship and deploying to Heroku successfully.
As a very short answer, the easiest way to get this running would be to add both bower and grunt to your dependencies in the package.json. Another possibility would be to look for a custom buildpack with both tools already installed.
And finally you could also run the tools on Codeship, add the newly installed files to the repository, commit the changes and push this new commit to Heroku. If you want to use this, you'd very probably need to force push the changes though.
Feel free to reach out to me via the in app messenger (lower right corner of the site) and I'd be happy to help you get this working!
I found two ways to get this to work.
Heroku Node Custom Buildpack
Use the mbuchetics Heroku build pack. This works by basically re-building the app once it has been pushed to Heroku.
There were a few tricks I had to employ still to make this work. In Gruntfile.jstwo new tasks needed to be configured called heroku:production and heroku:development. This is what the buildpack executes to build the app. I initially just aliased the main build task, but found that the either the buildpack or Heroku had a problem with running jshint so in the end I copied the build task and took out the parts that I didn't need.
Also in packages.json I had to add this:
"scripts": {
"postinstall": "bower cache clean && bower install"
}
This made sure the bower_components were available in Heroku.
Pros
This allowed me to keep the .gitignore file in tact so that the 'binaries' in the dist directory and the dependencies in the bower_components directory were not committed into source control.
Cons
This is basically re-building the app once it is on Heroku and I generally prefer to use the same 'binaries' throughout the entire build and deployment pipeline. That way I know that the same code that was built, is the same code that was tested and is the same code that was deployed.
It also slows down the deployment as you have to wait for the app to build twice.
CodeShip Custom Script Deployment
Not being satisfied with the fact I was building my app twice, I tried using a Custom Script pipeline in CodeShip instead of the pre-existing Heroku one. The script basically modified the .gitignore file to allow the dist folder to be committed and then pushed to the Heroku remote (which leaves the code on the origin remote unaffected by the change).
I ended up with the following bash script:
#!/bin/bash
gitRemoteName="heroku_$APP_NAME"
gitRemoteUrl="git#heroku.com:$APP_NAME.git"
# Configure git remote
git config --global user.email "you-email#example.com"
git config --global user.name "Build"
git remote add $gitRemoteName $gitRemoteUrl
# Allow dist to be pushed to heroku remote repo
echo '!dist' >> .gitignore
# Also make sure any other exclusions dont apply to that directory
echo '!dist/*' >> .gitignore
# Commit build output
git add -A .
herokuCommitMessage="Build $CI_BUILD_NUMBER for branch $CI_BRANCH. Commited by $CI_COMMITTER_NAME. Commit hash $CI_COMMIT_ID"
echo $herokuCommitMessage
git commit -m "$herokuCommitMessage"
# Must merge the last build in Heroku remote, but always chose new files in merge
git fetch $gitRemoteName
git merge "$gitRemoteName/master" -X ours -m "Merge last build and overwrite with new build"
# Branch is in detached mode so must reference the commit hash to push
git push $gitRemoteName $(git rev-parse HEAD):refs/heads/master
Pros
This only require a single build of the app and deploys the same binaries that were tested during the test phase.
Cons
I've used this script quite a few times now and it seems relatively stable. However one issue I know of is that when a new pipeline is created there will be no code on the master branch so this script fails when it tries to do the merge from the heroku remote. At the moment I get around this by doing an initial push of the master branch to Heroku before kicking off a build, but I imagine there is probably a better Git command I could run along the lines of; 'only merge this branch if it already exists'.
I installed SQLite into my WPF project via Nuget. Then added the entire project to a remote repo. Then I cloned the project on another machine, and had a broken build.
x64\SQLite.Interop.dll was missing.
I'm puzzled why Git didn't include one file from my project. I checked the repo on BitBucket and confirmed it is not there. Git status reports nothing to commit, working directory clean
It added the x86 version, but not the x64 version, I can't imagine why.
(project)\x64\SQLite.Interop.dll Git ignored this file!
(project)\x86\SQLite.Interop.dll
You might want to check the .gitignore file at the root of the repo. If it contains for example x64, it would ignore this file.
There would be two main possibilities then:
edit this file to fit your need
or force this file to be added; ie: git add -f x64/SQLite.Interop.dll
However, committing binary files is often frowned upon. It's true in particular if you want to keep up to date with the latest package, hence if you plan to commit new versions of the dlls on a regular basis.
You might rather want to consider Nuget package restore feature. Basically the idea is that you commit a config file, and the client will automatically download the corresponding packages.
I want to make the system updates based on composer
With updating dependencies no special problems, but how to update the root package, it is not clear
I'm trying to understand the code composer and so far without success
I think a root project put into dependencies and leave only the bare minimum
or download the project archive from the github and manually remake it
Maybe someone faced with such a task
I don't think there is any way to update the main project.
This is when you've, say, installed a project with composer create-project proj/name . * or similar? Running composer update of course updates the dependencies, but nothing exists to update the project itself.
One way to do it might be as you say, and make the root project nothing but a composer.json file that lists the dependencies, and move the project to operate as a dependency. Bit of a change to the structure though, so this mightn't be possible.
You'll have to use git to do this. This is currently not possible using composer. I was faced with the same problem.
Publish your project on github (or another service)
Install git on the server
Clone the project from git (using git clone git#github.com:whatever folder-name) onto your server wherever you want your root folder located
Whenever you need to update the root project, open a git command window from the root project directory, and run git pull origin v1.0.1. This will essentially patch the project files from the tag you specify.
I have a drupal installation running on OpenShift. I have been installing all modules and themes using git (commandline). However, I attempted to install the modules directly and the installation worked.
The problem that I now face is that when I attempt a pull request all I get is the modules and themes I had installed using the commandine and not the ones that I installed 'directly'.
Any one with a heads up on this?
OpenShift runs your code form a checkout of the git repository located at ~/app-root/repo within your gear. When you upload files using Drupal (instead of the git repository), the modules and themes are installed in this checked out directory and are not tracked in git.
I you are using a scaled application, I would recommend that copy the modules/themes and check them into git instead of the Drupal install method.
For now, to retrieve all your files you can try the rhc export command.
Thanks to #kraman above I got a hint of what to do.
I ran rhc snapshot save -a appname and got all the files. At least I know where to start off from since I can access the files.
A word of caution though for drupal users on openshift, just use git or sftp for pushing files and save yourself the headache.