How to install phalcon version 2 - phalcon

I have some applications built on phalcon version 2, but since the release of the version 3, new installations of phalcon default to version 3.

You need to install phalcon from source, but instead of build from the master branch switch the branch to the 2.0.x branch.
git clone --depth 1 https://github.com/phalcon/cphalcon.git
cd cphalcon
git remote set-branches origin '2.0.x'
git fetch --depth 1 origin 2.0.x
git checkout 2.0.x
cd build
./install
I created this gist to make this easier - https://gist.github.com/goke-epapa/c325da217296ec4880850972be955bf0
UPDATE
I've been told that the above snippet installs version 2.0.10, so the snippet below is specifically for version 2.0.13
git clone --depth 1 https://github.com/phalcon/cphalcon.git
cd cphalcon
git remote set-branches origin 'phalcon-v2.0.13'
git fetch --depth 1 origin phalcon-v2.0.13
git checkout phalcon-v2.0.13
cd build
./install
Update
Both code snippets were missing the cd cphalcon command so I modified the snippets.

Related

NPM Version Not Committing Workspace package.json

When trying to set the version of all work-spaces I have found that only the root workspace change is committed. Steps to reproduce using Angular CLI:
ng new test-workspace --create-application false
cd test-workspace
ng generate application test-app
git add --all
git commit -m "Application"
ng generate library test-lib
git add --all
git commit -m "Library"
Change root-level package.json to include:
"workspaces": [
"projects/test-lib"
]
git add --all
git commit -m "Workspaces"
npm version --workspaces --include-workspace-root true --workspaces-update false 0.0.2
After the final step test-lib/package.json has been changed to the new version but has not been commited.

gitlab runner doesn`t work on a specific project

I registered 11 projects of GitLab runner. Runners of each project work fine except 1 project. First time I registered runner of this project, it works.
But after I commit/push some changes, an error occurs and failed job.
I saw some solutions that upgrading the git version solved a problem, but I don't think so. Because all of the runners work fine except this project.
Server OS: CentOS 7
git: 1.8.3.1
First time registered runner
>Running with gitlab-runner 11.9.2 (...)
on (...)
Using Shell executor...
Running on localhost.localdomain...
Initialized empty Git repository in /home/gitlab-runner/(...)/.git/
Clean repository
Fetching changes with git depth set to 50...
Created fresh repository.
From https://gitlab.com/(...)
* [new branch] master -> origin/master
Checking out (...) as master...
Skipping Git submodules setup
$ echo "> gitlab-ci started"
> gitlab-ci started
$ cd /home/(..)
$ echo "> git pull started"
> git pull started
$ git pull
remote: Total 0 (delta 0), reused 0 (delta 0)
Already up-to-date.
Job succeeded
Second commit/pull, then
>Running with gitlab-runner 11.9.2 (...)
on (...)
Using Shell executor...
Running on localhost.localdomain...
Reinitialized existing Git repository in /home/gitlab-runner/(...)/.git/
Clean repository
Fetching changes with git depth set to 50...
fatal: remote origin already exists.
fatal: git fetch-pack: expected shallow list
ERROR: Job failed: exit status 1
edit. here is my .gitlab-ci.yml
stages:
- deploy
deploy_to_master:
stage: deploy
script:
- echo "> gitlab-ci started"
- cd /home/www/dir
- echo "> git pull started"
- git pull
- echo "> permission set"
- chmod 707 -R ./data/
- chmod 707 -R ./plugin/nice/
- chmod 707 ./favicon.ico
- echo "> server reload(=httpd -k graceful)"
- systemctl reload httpd
only:
- master
tags:
- tags
There are a few options to fix this. The problem is the version of git on your runner is too old. And sometimes you can't update git on the runner.
Options to fix:
Upgrade to a newer version of git on the runner.
In .gitlab-ci.yml, use the option to git clone:
variables:
GIT_STRATEGY: clone
Configure Gitlab, change Git strategy for pipelines of the project to "git clone".
3.1. In the Gitlab web gui,
3.2. go to your project,
3.3. then: "Settings -> CI / CD -> General pipelines".
3.4. Change the options for:
"Git strategy for pipelines" to: "git clone"
"Git shallow clone" to: 0
Centos 7 ships with git version 1.8.3.1 . This version doesn't support commands like git fetch-pack . To fix this problem, you could update git on your server from the IUS repository.
update git on Centos 7 to version 2 from third-party IUS repo
$ git --version
git version 1.8.3.1
sudo yum -y install https://packages.endpointdev.com/rhel/7/os/x86_64/endpoint-repo.x86_64.rpm
sudo yum install git
You can go around this problem without upgrading git at all:
1. Clone Strategy
Set in .gitlab-ci.yml:
variables:
GIT_STRATEGY: clone
Now every change you make will trigger re-cloning the project, avoiding the need of the problematic git fetch-pack command.
2. Manually Remove Project Directory (not recommended)
Remove manually the build directory from gitlab-runner server, so it will have to clone it again.
For project testgroup/testproject, run:
careful with rm commands!
rm -rf /home/gitlab-runner/builds/UwnzuxxL/0/testgroup/testproject
Notice that after builds directory you have a random string that will be different from this example.
Check value in your project's CI/CD settings on gitlab.com. If there is any value in 'git shallow clone' remove it and save changes. Now your pipeline will work as expected.
I had a similar issue, and I had to update Git. Centos 7 comes with git-1.8.x which has limitations around gitlab-ci.
Upgrade your git, based on this guide.
I made a new project and, finally, it works fine. I don't know why the other one didn't work. If the same problems occurs like mine, don't get too serious: Just make a new gitlab project. It is good for your mental well-being.
rm -fr /home/gitlab-runner/(...) , clean then exists repository

update the version in package.json without clean git working directory (without a task runner like Gulp)

When running a: npm version prepatch I get the error: "Git working directory not clean." And then a list of files that aren't committed yet.
However, I'd like to do this prerelease to test some stuff locally using a private npm registry. Meaning that I don't have to commit the files just yet using Git.
Is it possible to update the version in package.json without clean git working directory?
From the npm version documentation at https://docs.npmjs.com/cli/version:
If run in a git repo, it will also create a version commit and tag. This behavior is controlled by git-tag-version (see below), and can be disabled on the command line by running npm --no-git-tag-version version. It will fail if the working directory is not clean, unless the -f or --force flag is set.
I'm not 100% certain whether you just need --no-git-tag-version, or if you'll also need the --force flag.
You can use git stash.
E.g.
git stash
npm version patch
git stash pop
This will reset your working directory temporarily (remove uncommitted changes). Then you can run npm version {major|minor|patch}. Afterwards, using git stash pop will re-apply your uncommitted changes to your working directory.
Tutorial: https://www.atlassian.com/git/tutorials/saving-changes/git-stash#stashing-your-work
Try to commit first
git add . && git commit -am "new version"
and then
npm version patch

How to install bower component with git submodules as a dependency?

I have a library which requires 2 dependencies to exist in the "vendor" directory. This library has these 2 dependencies installed as git submodules on Github, so to install my library from a Git clone you would do:
git clone --recursive https://github.com/MYLIBRARY.git
And to install it as another Git submodule, you would do:
git submodule add https://github.com/MYLIBRARY.git && git submodule update --init --recursive
The issue comes when trying to install it with Bower, as the Git submodules do not get downloaded with the bower package (the dependency folders exist, but are empty). The 2 dependencies exist separately on bower, but as they are required to be in the "vendor" directory of the main library, I cannot include them as bower dependencies. I also can't assume that any project installing my library will be a Git repo, so I can't do something like:
bower install MYLIBRARY && git submodule update --init --recursive
Which would work if the parent project you installed my library in was a Git repo, but would error if not.
I'm worried I may have to have an instruction similar to:
bower install MYLIBRARY && cd bower_componets/MYLIBRARY && git clone https://github.com/DEPENDENCY1.git vendor/DEPENDENCY1 && git clone https://github.com/DEPENDENCY2.git vendor/DEPENDENCY2
This can be tidied slightly by adding an npm run script in package.json:
"scripts": {
"bower_vendor": "git clone https://github.com/DEPENDENCY1.git vendor/DEPENDENCY1 && git clone https://github.com/DEPENDENCY2.git vendor/DEPENDENCY2"
}
Then the installation instruction would become:
bower install MYLIBRARY && cd bower_componets/MYLIBRARY && npm run bower_vendor
Which is a little neater, but again wouldn't work if the user has customised their bower_components directory (which is simple enough to change in the above command, but is still another concern).
I'm hoping I've just missed something somewhere which will solve my issue. I read that bower performs a git clone of the repo, so if there was a way to get it to perform git clone --recursive that would be amazing.
Thanks

Restart Git repo Xcode 4.3.2

For different changes I made in my project, I need to restart Git repo and start with a new fresh version with the current project. How can I achieve this?
Many thanks
fire up your terminal:
go to project
cd myPath/MyProject
delete the current repo on your disk - your git repo = RIP
rm -Rf .git
init a new repo
git init
add your project to the new git repo
git add .
commit
git commit -a -m "init Project XY"
check if the repo is o.k
git status
What you want to do is create a new empty branch without any history. That way you start fresh but still have the option to return to your previous content. Inside the git repository, enter these commands:
git symbolic-ref HEAD refs/heads/<branchname>
rm .git/index
git clean -fdx
After that you are in the same situation as with an empty repository (i.e. start adding and commiting files) except that the history still exists in your old branches.
Note that all files you don't have in your old version will be permanently removed.