I want to assess SonarQube as a source code inspection tool.
The project is hosted in a git repository, and I want to SonarQube to check my PHP project on each commit.
I got a basic instance of SonarQube via docker. (The current version of sonar cube is 6.7 -- yet I do not know if the steps remain the same. This answer takes into account 5.1.)
Run the container:
sudo docker run -d --name sonarqube -p 9000:9000 -p 9092:9092 sonarqube:5.1
This provides with a standard install of SonarQube accessable at
http://localhost:9000/
I can login via username and passoword admin, and install the PHP component via:
Settings > System > Update Center
(or: http://localhost:9000/updatecenter )
and search for PHP and install.
There I can add PHP and after restart of the SonarQube server, (I did it via docker stop container_id, container start container_id), the extension is loaded.
The server will not run your tests. It will only display the results.
You will need a machine dedicated to work as your sonar-runner, for a quick start you may use your local dev machine and your local checkout from bitbucket. Install the sonar-runner on that machine.
Download the sonar runner via:
$ wget http://repo1.maven.org/maven2/org/codehaus/sonar/runner/sonar-runner-dist/2.4/sonar-runner-dist-2.4.zip
and extracted it to:
~/programs/sonar-runner-2.4
In this directory, there you find a file conf/sonar-runner.properties that should contain:
#Configure here general information about the environment, such as SonarQube DB details for example
#No information about specific project should appear here
#----- Default SonarQube server
sonar.host.url=http://localhost:9000
#----- PostgreSQL
#sonar.jdbc.url=jdbc:postgresql://localhost/sonar
#----- MySQL
#sonar.jdbc.url=jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8
#----- Oracle
#sonar.jdbc.url=jdbc:oracle:thin:#localhost/XE
#----- Microsoft SQLServer
#sonar.jdbc.url=jdbc:jtds:sqlserver://localhost/sonar;SelectMethod=Cursor
#----- Global database settings
sonar.jdbc.username=sonar
sonar.jdbc.password=sonar
#----- Default source code encoding
sonar.sourceEncoding=UTF-8
#----- Security (when 'sonar.forceAuthentication' is set to 'true')
sonar.login=admin
sonar.password=admin
Go into your project's root directory and create a file called sonar-project.properties:
# must be unique in a given SonarQube instance
sonar.projectKey=yourProjectKey
# this is the name displayed in the SonarQube UI
sonar.projectName=yourProject
sonar.projectVersion=1.0
# Path is relative to the sonar-project.properties file. Replace "\" by "/" on Windows.
# Since SonarQube 4.2, this property is optional if sonar.modules is set.
# If not set, SonarQube starts looking for source code from the directory containing
# the sonar-project.properties file.
sonar.sources=./classes/,./tests/
# Encoding of the source code. Default is default system encoding
sonar.sourceEncoding=UTF-8
# Encoding of the source code. Default is default system encoding
sonar.sourceEncoding=UTF-8
I then ran:
your/projects/dir$: ~/programs/sonar-runner-2.4/bin/sonar-runner
You will then see an new entry at your SonarCube dashboard.
Get the following:
OpenJDK: 7u55+ of 8
MySQL: 5.1 t/m 5.7
SonarQube: http://dist.sonar.codehaus.org/sonarqube-5.1.zip
Sonar Runner: http://repo1.maven.org/maven2/org/codehaus/sonar/runner/sonar-runner-dist/2.4/sonar-runner-dist-2.4.zip
Do the following:
Installation: http://docs.sonarqube.org/display/SONAR/Installing
Setup SonarRunner:
#Configure here general information about the environment, such as SonarQube DB details for example
#No information about specific project should appear here
#----- Default SonarQube server
sonar.host.url=http://14.3.1.4:9000
#----- PostgreSQL
#sonar.jdbc.url=jdbc:postgresql://localhost/sonar
#----- MySQL
sonar.jdbc.url=jdbc:mysql://14.3.1.2:3306/sonarqube? useUnicode=true&characterEncoding=utf8
#----- Oracle
#sonar.jdbc.url=jdbc:oracle:thin:#localhost/XE
#----- Microsoft SQLServer
#sonar.jdbc.url=jdbc:jtds:sqlserver://localhost/sonar;SelectMethod=Cursor
#----- Global database settings
sonar.jdbc.username=sonarqube
sonar.jdbc.password=sonarqube
#----- Default source code encoding
sonar.sourceEncoding=UTF-8
#----- Security (when 'sonar.forceAuthentication' is set to 'true')
#sonar.login=admin
#sonar.password=admin
Clone a git repo in the var/www folder on the server where sonar is at.
Then add a configurationfile in the project you want to check called sonar-project.properties. Here is an Symfony example:
# Required metadata
sonar.projectKey=yoursite.dev.nl.project
sonar.projectName=Project
sonar.projectVersion=1.0
# Comma-separated paths to directories with sources (required)
sonar.projectBaseDir=/var/www/your_project
# Folder being analysed.
sonar.sources=symfony/src
# Language (Only when it is a single language)
sonar.language=php
# Encoding of the source files
sonar.sourceEncoding=UTF-8
Related
I have been trying and failing for a week to get Kalabox working with a WordPress install that has a nested web root with Pantheon. I've found some great resources, but many of them are for Drupal and they don't seem to translate to the WP installs, like the great post by Tandem here: https://www.thinktandem.io/blog/2017/05/20/using-pantheon-s-nested-docroot-with-kalabox/
Does anyone have a quick walkthrough that would work? Thanks!
I figured it out! Here's what it took:
1. Setup A Site In Pantheon
Create Sites
2. Clone the Site to your local machine using Kalabox
Make sure you've installed Kalabox on your machine. This will also install Docker, if you haven't already installed it. Now, open your terminal.
mkdir -p ~/Kalabox
cd ~/Kalabox
kbox create pantheon
# follow the prompts to clone down your Pantheon site
3. Add Your Site Code
This is where the real work starts. Make sure you're in the main Kalabox directory. I'm using the excellent Advanced Wordpress On Pantheon as the boilerplate for this app. But you can use whatever you'd like.
# replace text in < > with your site name
cd ~/Kalabox/<your-site-name>
rm -rf code/
# Clone this or copy your own site code into the code directory
git clone https://github.com/ataylorme/advanced-wordpress-on-pantheon.git code
If you're using the Advanced WordPress install above, type the following lines, as well:
cd code/
./bin/local-build.sh
Make certain you added your code into the ~/Kalabox/<your-site-name>/code/ directory.
You can visit your site now at http://.kbox.site on your browser, but if you have a nested web root, you'll likely see an Nginx 500 error. This is the problem we're trying to fix!
4. Edit The Kalabox Setup to Allow A Nested Web Root
This part is the secret sauce. We have to get into the Docker container that Kalabox has setup and change the nginx configuration files. If all that sounds like non-sense to you, don't worry. These simple instructions should help you do it! Back to the terminal!
docker ps
This dumps a table with a list of the running Docker containers. Find the one that says nginix under the Image column. Look immediately to the left in the Container ID column. Note, copy and/or write down the first four-or-so letters of that container ID. You'll use those in the <container-id> part of this next command:
docker exec -i -t <container-id> bash
This opens a pseudo remote shell with your nginx container. Yay! Now we can edit the nginx files and get our site up-and-running! The command line probably changed a bit, showing your user as root#<your-site-name>. That means it worked.
The nginx container doesn't have a text editor downloaded by default. So, we'll download a tiny little text editor called Nano.
apt-get update
apt-get install nano
Once those commands are finished running, we can edit the config file:
nano /etc/nginx/conf.d/default.conf
This opens the Nano editor with the configuration file we're trying to edit. Look and change the following lines:
# This one is near the top of the file
# Before
root /code;
# After
root /code/web;
# These next two are near the bottom of the file.
# This exact line appears twice--once in the `location ~ ^/simplesaml/`
# block, and once in the `location ~ \.php$` block. Edit it in
# BOTH locations.
#
# Before
fastcgi_param SCRIPT_FILENAME /code/$fastcgi_script_name;
# After
fastcgi_param SCRIPT_FILENAME /code/web/$fastcgi_script_name;
When you're done with that, type <Ctrl-o> <Enter> <Ctrl-x> to save your work and exit. You're back at the pseudo shell for your Docker container. Type exit to go back to your normal command line.
5. Rebuild Kalabox & Test It Out!
Make sure you're in the ~/Kalabox/<your-site-name> directory, and type kbox restart just to make sure you've got everything cleared out of the Kalabox caches. Kalabox will stop and restart your site for you. Once it's done, visit http://.kbox.site in your browser to see your work!
Extra Goodies
Upgrade to PHP 7: Open ~/Kalabox/<your-site-name>/kalabox.yml in your favorite editor, and change line 33 to php: 70.
Remove Undefined Index: NONCE_KEY error: open ~/Kalabox/<your-site-name>/config/php/prepend.php and go to roughly line 55 which reads $_ENV['NONCE_SALT'] = getenv('NONCE_SALT');. Below it, add a similar line: $_ENV['NONCE_KEY'] = getenv('NONCE_KEY');
I have trouble deploying with Deployer 4.0.2 and I am in need for help of somebody more experienced than me in this.
I want to deploy a repository of mine to a Ubuntu 16.04 server.
I am using laravel homestead as a development environment, where I also installed deployer. From there I ssh into my remote server.
I was able to deploy my code with the root user, until I hit a RuntimeExceptionthat aborted my deployment.
Do not run Composer as root/super user! See https://getcomposer.org/root for details
That made me create another user called george, whom I gave superuser rights. I copied my public key from my local machine to a newly generated ~/.ssh/authorized_keys file, that gave me permission to access the server via ssh.
Yet when I run dep deploy with the new user:
server('production', '138.68.99.157')
->user('george')
->identityFile()
->set('deploy_path', '/var/www/test');
I get another RuntimeException:
Host key verification failed.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Now it looks like the new user george cannot access the ~/.ssh/id_rsa.pubkey. So I copy them from the root folder into my home folder and also add the public key in the Github SSH settings.
cp root/.ssh/id_rsa.pub home/george/.ssh/id_rsa.pub
cp root/.ssh/id_rsa home/george/.ssh/id_rsa
Only to get the same error as before.
In the end I had to add github to my list of authorized hosts:
ssh-keyscan -H github.com >> ~/.ssh/known_hosts
Only to get the next RuntimeException
[RuntimeException]
sudo: no tty present and no askpass program specified
I managed to comment this code in the deploy.php
// desc('Restart PHP-FPM service');
// task('php-fpm:restart', function () {
// // The user must have rights for restart service
// // /etc/sudoers: username ALL=NOPASSWD:/bin/systemctl restart php-fpm.service
// run('sudo systemctl restart php-fpm.service');
// });
// after('deploy:symlink', 'php-fpm:restart');
to get the deployment process finally done, and now I ask myself, if the restart of php-fpm is really necessary, for me to continue debugging this deployment tool? Or can I live without it?
And if I need it, can somebody help me understand what I need it for? And maybe as a luxury also provide the solution to the RuntimeException?
Try this:
->identityFile('~/.ssh/id_rsa.pub', '~/.ssh/id_rsa', 'pass phrase')
It works great for me - no need for an askpass program.
It helps to be explicit in my experience.
As for your phpfm restart task .. I haven't seen that before. Shouldn't be needed. :)
EDIT:
That you provide a password is probably a good sign that you ought to refactor your Deployer code a bit if you keep it under source control.
I am loading site specific data from a YAML file - which I am not submitting to source control.
The first bit of my stage.yml :
# Site Configuration
# -------------
prod_1:
host: hostname
user: username
identity_file:
public_key: /home/user/.ssh/key.pub
private_key: /home/user/.ssh/key
password: "password"
stage: production
repository: https://github.com/user/repository.git
deploy_path: /var/www
app:
debug: false
stage: 'prod'
And then, in my deploy.php :
if (!file_exists (__DIR__ . '/deployer/stage/servers.yml')) {
die('Please create "' . __DIR__ . '/deployer/stage/servers.yml" before continuing.' . "\n");
}
serverList(__DIR__ . '/deployer/stage/servers.yml');
set('repository', '{{repository}}');
set('default_stage', 'production');
Notice that, when you use serverList, it replaces your server setup in deploy.php
I'm deploying code to a single-instance web server AWS EB environment that will provision/update my connected RDS database. I've got an .ebextensions file that calls deployment code:
---
container_commands:
01deploydb:
command: /var/www/html/php/cli/deploy-db.php
leader_only: true
On the same deployment, I dropped the deploy-db.php file back one directory into /cli/. On deployment, I get ERROR: [Instance: i-*****] Command failed on instance. Return code: 127 Output: /bin/sh: /var/www/html/php/cli/deploy-db.php: No such file or directory.
container_command 01deploydb in .ebextensions/01_db.config failed. For more detail, check /var/log/eb-activity.log using console or EB CLI.
If I deploy a version that does not include the command, then deploy a second update including the command, there is no error. However, adding the command and the file it calls at the same time produces the error. A similar sequence occurred earlier with a different command/file.
My question is: is there a documented order/sequence for how AWS updates the environment? I would have expected that my new version would have fully deployed (and the .php file installed) before container_commands are called.
The commands: section runs before the project files are put in place. This is where you can install server packages for example.
The container_commands: section runs in a staging directory before the files are put in its final destination. Here you can modify your files if you need to. Current path is this staging directory so you can run it like this (I might get the app directory wrong, maybe it should be php/cli/deploy-db.php)
container_commands:
01deploydb:
command: cli/deploy-db.php
leader_only: true
Reference for above: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-ec2.html
You can also run a post deploy scripts. This is not very well documented (at least it wasn't). You can do something like this (it won't be leader only though, but you could put a file in this directory through a container_commands:):
files:
"/opt/elasticbeanstalk/hooks/appdeploy/post/99_deploy.sh":
mode: "000755"
owner: root
group: root
content: |
#!/usr/bin/env bash
/var/www/html/php/cli/deploy-db.php
My application folder name is "social_network". It is in wamp\www path. I am trying to deploy app folder("social_network") to heroku using git commands.I followed all the instructions of heroku's instructions pages. I included composer.json file in the app folder, installed composer, kept Procfile. I even gave the commands of "heroku buildpacks:set".But still the push is being failed with an error message "set buildpack failed".The code in Procfile is:
"web: vendor/bin/heroku-php-apache2." Is this the process type to be given for the app in wamp server? What folder should I try to deploy- wamp or social_network?I doubt if there will be any more changes to make inorder to deploy as it is developed using wamp server.How can I deploy successfully?
The mistake that I had done was having the files of composer.json and Procfile along with my php files under social_network folder while the repository was created in www folder(I had my .git folder in www folder). So, heroku was not able to recognize my app as a php app and the push failed.
As I had a great difficulty to deploy my php application that was developed through wamp server, I would like to explain all the steps involved in deploying the php app which needs a database to heroku.
It is better to have all the application files directly under www folder.
The following documentation can be referred:
Getting started with heroku for php:
Have a heroku account, install php, and install composer and run it. The composer will download required packages in a folder called vendor which should be in your app directory.
Download heroku CLI and login to heroku using the command:
heroku login
Include composer.json file so that heroku recognizes that the application is a php app. It should contain the following code:
{
"require": {
"php": "^5.5.12"
}
}
The above code will instruct Heroku to use the latest version of PHP 5. The version can be anything which your app uses.
Have a Procfile to declare what command should be executed to start the app. It should have the following code:
web: vendor/bin/heroku-php-apache2
Now in cmd, make sure that the path of your www folder:
c:\wamp\www>
If there are any changes made to composer.json file, update the composer.lock file by:
c:\wamp\www> update composer
Next, create a new repository in the www folder by:
c:\wamp\www>git init
Then add your files to the repository.
c:\wamp\www>git add .
Then commit:
c:\wamp\www>git commit
Then create an app in heroku
c:\wamp\www>heroku create
Then comes the part of creating database and establishing connection:
The following documentation can be referred:
ClearDb Database documentation for php by heroku
Create a database:
C:\wamp\www>heroku addons:create cleardb:ignite
Set the url of the database to the app created in heroku:
C:\wamp\www> heroku config:set DATABASE_URL='the url that was created by the above command'
To know the CLEARDB_DATABASE_URL:
C:\wamp\www>heroku config
which gives the url:
CLEARDB_DATABASE_URL= mysql://user:password#host/heroku_db?reconnect=true
Example of the CLEARDB_DATABASE_URL:
mysql://b8xxxxxx:edxxxx# us-cdbr-iron-east-04.cleardb.net/heroku_xxxxxx?reconnect=true .
To dump the existing sql file to the sql database in heroku, make sure that the PATH had been set for mysql and then give the following commands:
To get a mysql prompt with connection to the database.
C:\wamp\www>mysql -u b8xxxxxx -h us-cdbr-iron-east-04.cleardb.net -p heroku_xxxxxx
To dump the existing file to heroku database:
C:\wamp\www>mysql --host=us-cdbr-iron-east-04.cleardb.net --user=b8xxxxxx --password=edxxxxxx --reconnect heroku_xxxxxx< yoursqlfile.sql
Now use the database created and connect to it in your code:
<?php
$url = parse_url(getenv("CLEARDB_DATABASE_URL"));
$server = $url["host"];
$username = $url["user"];
$password = $url["pass"];
$db = substr($url["path"], 1);
$con = mysqli_connect("$server", "$username", "$password", "$db");
?>
Then push to the app created in heroku:
c:\wamp\www>git push heroku master
Open the app:
c:\wamp\www>heroku open
That's it! Now the website is hosted onto heroku successfully!
I am running into an issue with a customer's Drupal sites. He has a number of D6 installs, and a new D7 that he's just starting on. All of these sites are on the same shared hosting package.
The problem is when running certain drush commands only on the D7 site. There are no issues on the D6 sites. The specific error for drush up on the D7 site follows:
foo#bar [~/www/foo]# drush up
Command pm-update needs a higher bootstrap level to run - you will need to invoke drush [error]
from a more functional Drupal environment to run this command.
Command pm-update needs the following modules installed/enabled to run: update. [error]
The drush command 'up' could not be executed. [error]
Drush was not able to start (bootstrap) the Drupal database. [error]
Hint: This may occur when Drush is trying to:
* bootstrap a site that has not been installed or does not have a configured database. In
this case you can select another site with a working database setup by specifying the URI
to use with the --uri parameter on the command line. See `drush topic docs-aliases` for
details.
* connect the database through a socket. The socket file may be wrong or the php-cli may
have no access to it in a jailed shell. See http://drupal.org/node/1428638 for details.
Drush was attempting to connect to:
Drupal version : 7.28
Site URI : http://default
Database driver : mysql
Database username : username_foo
Database name : database_foo
PHP configuration :
PHP OS : Linux
Drush version : 7.0-dev
Drush temp directory : /tmp
Drush configuration :
Drush alias files :
Drupal root : /home/foo/www/foo
Site path : sites/default
Everything I can find (and indeed the link in the error message) say the solution is to change the host value in the settings.php file from localhost to 127.0.0.1. However, this has not been the solution for us.
The frontend site has no problems connecting to the database, and drush itself seemingly does in many cases too.
drush sql-connect will generate a string that you can use to connect to MySQL.
drush sql-cli will successfully connect to MySQL
The settings.php file is definitely in a folder called default (path: www/foo/sites/default) and I get the exact same error when specifying --root and --uri options.
Drush was originally a ~5.x release, and it had the same issues. We updated to the ~7.x to try to eliminate the error. The host value in settings.php has been localhost as well as 127.0.0.1 with equally poor results.
We've verified that MySQL is available via socket from the PHP CLI. Drush is up to date and a fresh install. The Drupal 7 site is a brand new fresh install.
I'm at a loss. Why would this work with the D6 sites, but not the D7? Any suggestions?
Is your settings.php file in a folder called 'default'? If not, you might need to tell Drush where to find it by using --uri=mysite.com or -l mysite.com.
There are several ways to specify which Drupal site Drush will target. The most basic option is fairly verbose; run:
$ drush --root=/path/to/drupal --uri=http://example.com status
You can do the same thing with a slightly different syntax:
$ drush /path/to/drupal#example.com status
You can also specify the Drupal site implicitly, by setting the cwd to the folder that contains the settings.php file for your site:
cd /path/to/drupal/sites/default # or /path/to/drupal/sites/mysite.com, as appropriate
$ drush status
In all of the cases above, if settings.php is in a folder called "default", then you do not need to specify the --uri component; you may, for example, cd /path/to/drupal followed by drush status, and the correct Drupal site will be found. If settings.php is not in a folder named 'default', then you will need to either specify --uri, or cd to the folder that contains the settings.php file.
Source
According to this message:
pm-update needs the following modules installed/enabled to run: update
Drush requires Update module to be enabled, so the following command should fix the problem:
drush -y en update