How do i configure .gitlab-ci.yml to build my django project - django

I have succesfully installed and configured gitlab and gitlab-ci-multirunners. What i want to do now is configure the .gitlab-ci.yml file so that it runs python manage.py test and succeed if the tests pass and fail otherwise.
What would be the best approach to achieve this?

test_app:
script: python manage.py test
Something like the above should do it. Note, the exit code of the script command determines if the build passes or fails. If you need multiple lines of shell scripts you can use a yaml list:
test_app:
script:
- python dosetup.py
- python manage.py test
test_app is the name of the build job while the script property defines the shell commands to run for the given build job. When using multiple script lines, each line is run as a separate command. If any of the lines return exit code != 0 the build will fail.
By default a build job in .gitlab-ci.yml runs as test. If you need multiple types of build steps you can define them as such:
types:
- build
- test
build_app:
type: build
script: echo Building!
test_app:
type: test
script: python manage.py test
More info in the official documentation: https://docs.gitlab.com/ce/ci/yaml/

Related

Why does google cloud build run differently for these two commands?

We run these two commands (the first one is async and the other runs synchronously)
#async BUT does something funky and doesn't run the Dockerfile image as-is
gcloud alpha builds triggers run staging-deploy --branch master
# sync BUT runs the image the way it's supposed to run!!!
gcloud builds submit --config cloudbuild.yaml
both are using our cloudbuild.yaml
steps:
- name: gcr.io/$PROJECT_ID/continuous-deploy
args: ['${_SERVICE}', '${_DOWNLOAD_URL}']
timeout: 1000s
substitutions:
_SERVICE: none
_DOWNLOAD_URL: none
timeout: 1100s
Our Dockerfile is very very simple
FROM gcr.io/google.com/cloudsdktool/cloud-sdk:alpine
RUN mkdir -p ./monobuild
COPY . ./monobuild/
WORKDIR "/monobuild"
#NOTE: This file in google cloud build trigger MUST be in root of monorepo BUT I don't know why
#NOTE: This command receives any arguments to docker
#ie. for "docker run {image} {args}", it receives the args
ENTRYPOINT ["./downloadAndExtract.sh"]
Sooo, when I run the SECOND command, it completely uses the docker image obeying the Dockerfile. When I run the first command, it's ignoring all my Dockerfile stuff and trying to run scripts in my git repo(which is very frustrating and not what I want).
We HAD this directory structure
- gitroot
- stagingDeploy
- Dockerfile
- deployStaging.sh # part of Dockerfile
- cloudbuild.yaml
- prodDeploy
- Dockerfile
- prodDeploy.sh #part of Docker file
- cloudbuild.yaml
Of course, only the second command works with this directory structure. The first command CANNOT find deployStaging.sh UNTIL we ln -s stagingDeploy/deployStaging.sh from our gitrepo root and we have around 5 deploy directories and now our git repo root is fully polluted.
It is to say the least very frustrating and we are not sure how to clean this up so prodDeploy contains all the prod deploy scripts and staging, the staging ones and get rid of all root files.
Of course, we now have a corrupted git repo directory structure with a whole slew of files in the root directory from various different builds(sometimes conflicting on accident as files get the same names sometimes).
EDIT: Not really much to share on configuration of twitter as each one just points to the yaml file is all like so
thanks,
Dean

Code coverage is always unknown in GitLab

I'm trying to understand the GitLab Pipelines and after a few tries I was able to successfully automate my unit tests. Now I'm trying to add the code coverage badge into my project and/or readme file but it always seems to show unknown.
Files:
+ application
+ system
- unit-tests
- tests
UtilTest.php
autoload.php
phpunit
.gitignore
.gitlab-ci.yml
.htaccess
index.php
readme.md
.gitlab-ci.yml:
image: php:5.6
stages:
- test
app:unit-tests:
stage: test
script:
- php ./unit-tests/phpunit --bootstrap ./unit-tests/autoload.php ./unit-tests/tests
coverage: '/Code Coverage: \d+\.\d+/'
On the project's Test coverage parsing section I have this set up:
So I was able to fix this by using PHP 7.2 as the Docker image and installing xdebug on the before_script call.
.gitlab-ci.yml:
image: php:7.2
stages:
- test
before_script:
- pecl install xdebug
- docker-php-ext-enable xdebug
app:unit-tests:
stage: test
script:
- php ./unit-tests/phpunit --bootstrap ./unit-tests/autoload.php ./unit-tests/tests --coverage-text --colors=never
coverage: '/^\s*Lines:\s*\d+.\d+\%/'
I had to use PHP 7.2 because when I tried running pecl install xdebug it said it requires PHP 7. Ideally I would like to use PHP 5.6 because that's what our current server has just so the tests are on similar versions but I'll leave it as it is for now.
I had to add --coverage-text --colors=never on the script call for it to output the numbers. Then on the coverage call I changed it to '/^\s*Lines:\s*\d+.\d+\%/' which I also used under the Test coverage parsing section on the project settings.
And now the code coverage properly shows me my expected values.

Google Cloud Container Build trigger crashes during gradle build

I was trying to setup a build trigger for an kotlin app that is build using gradle. For that I put together the following Dockerfile:
FROM gradle:jdk8 as builder
WORKDIR /home/gradle/project
COPY . .
WORKDIR ./Kuroji-Eventrouter-Server
RUN gradle shadowJar
FROM openjdk:8-jre-alpine
WORKDIR /app
COPY --from=builder /home/gradle/project/Kuroji-Eventrouter-Server/build/libs/kuroji-eventrouter-server-*-all.jar kuroji-eventrouter-server.jar
ENTRYPOINT ["java", "-jar", "kuroji-eventrouter-server.jar"]
And that file works on my machine with docker build and it starts normally on google container registry however during the RUN gradle shadowJar task it crashes with some gradle error:
Step 5/9 : RUN gradle shadowJar
---> Running in ddd190fc2323
Starting a Gradle Daemon (subsequent builds will be faster)
[91m
[0m[91mFAILURE: [0m[91mBuild failed with an exception.[0m[91m
[0m[91m
[0m[91m* What went wrong:
[0m[91mCould not create service of type ScriptPluginFactory using BuildScopeServices.createScriptPluginFactory().
[0m[91m> [0m[91mCould not create service of type CrossBuildFileHashCache using BuildSessionScopeServices.createCrossBuildFileHashCache().
[0m[91m
[0m[91m* Try:
[0m[91mRun with [0m[91m--stacktrace[0m[91m option to get the stack trace. Run with --info[0m[91m or --debug[0m[91m option to get more log output. Run with [0m[91m--scan[0m[91m to get full insights.[0m[91m
[0m[91m
[0m[91m* Get more help at https://help.gradle.org
[0m[91m
[0m[91mBUILD FAILED in 3s
The command '/bin/sh -c gradle shadowJar' returned a non-zero code: 1
ERROR
ERROR: build step 0 "gcr.io/cloud-builders/docker" failed: exit status 1
[0m
I tried building the Image on docker HUB and the same thing happend: https://hub.docker.com/r/usbpc/kuroji-eventrouter-server/builds/bnknnpqowwabdy82ydxiypc/
This is very confusing to me as I thought containers should be able to run anywhere and not depend on the enviroment. What can I do to make google build my container?
The problem was a file permission problem. Using the --stacktrace option I found that the gradle process didn't have permissions to create a folder inside the sources.
The solution I would like to do is use the --chown=gradle:gradle option on the COPY instruction, unfortunatly this it not supported in the google cloud yet.
So the solution is to add USER root before executing the gradle build.

Deploying golang app in cmd folder to AWS Beanstalk

I have a pre-existing golang project with the a following folder structure (minimized the folder for readability).
- postgre
- service.go
- cmd
- vano
- main.go
- vanoctl
- main.go
vano.go
Now since my project web server is in ./cmd/vano I need to create a custom Buildfile and Procfile. So I did that
Here is my Buildfile
make: ./build.sh
build.sh file:
#!/usr/bin/env bash
# Install dependencies.
go get ./...
# Build app
go build ./cmd/vano -o bin/application
and finally my Procfile:
web: bin/application
So now my folder structure looks like this:
- postgre
- service.go
- cmd
- vano
- main.go
- vanoctl
- main.go
vano.go
Buildfile
build.sh
Procfile
I zip up the source using git:
git archive --format=zip HEAD > vano.zip
And upload it to AWS Beanstalk. How ever I keep getting errors and AWS errors don't seem to be the most read. Here is my error
Command execution completed on all instances. Summary: [Successful: 0, Failed: 1].
Error Message
[Instance: i-0d8f642474e3b2c68] Command failed on instance. Return code: 1 Output: (TRUNCATED)...' Failed to execute 'HOME=/tmp /opt/elasticbeanstalk/lib/ruby/bin/ruby /opt/elasticbeanstalk/lib/ruby/bin/foreman start --procfile /tmp/d20170213-1941-1baz0rh/eb-buildtask-0 --root /var/app/staging --env /var/elasticbeanstalk/staging/elasticbeanstalk.env'. Hook /opt/elasticbeanstalk/hooks/appdeploy/pre/01_configure_application.sh failed. For more detail, check /var/log/eb-activity.log using console or EB CLI.
Extra Error info:
Failed to execute 'HOME=/tmp /opt/elasticbeanstalk/lib/ruby/bin/ruby /opt/elasticbeanstalk/lib/ruby/bin/foreman start --procfile /tmp/d20170213-1941-1baz0rh/eb-buildtask-0 --root /var/app/staging --env /var/elasticbeanstalk/staging/elasticbeanstalk.env'
Another approach here instead of using a procfile etc would be to cross-compile your binary (usually pretty painless in go) and upload it that way, as per the simple instructions in the guide:
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/go-environment.html
You can just compile it locally with:
GOARCH=amd64 GOOS=linux go build -o bin/application ./cmd/vano
Then upload zip of the application file and it should work, assuming your setup only requires this one binary to run.

Starting a Django virtual environment in Grunt

Coming from a JS / Node development background, I like to use Grunt for a lot of my automation. For a recent project I picked up some baby Django, to get a feel for how it operated, but still wanted to integrate Grunt for some of my workflow.
I am currently starting my Django server via Grunt, using the spawn-shell module. This works just fine, but I am also using a virtualenv setup, and would as well like to start that up via Grunt.
The command I am using to start the virtual enviornment is:
source ./venv/bin/activate
Which works just fine from the terminal command line as is. However, executing this command from either grunt shell or grunt exec does nothing. I get no errors from Grunt (it says running, then done without errors), but nothing gets started.
The grunt exec command is as follows:
exec: {
start: {
cmd: function() {
return "source ./venv/bin/activate";
}
}
}
And the shell command is:
shell: {
start: {
command: 'source ./venv/bin/activate',
options: {
stdout: true
}
}
}
Any ideas on how to get this working? Or is it not possible, and I should just resort to entering the command manually at start?
Normally when trying to get other tooling to launch django while using a virtualenv the normal thing is to perform both of the following in one command :
activate the virtualenv
run the command you want.
so this ends up being :
. ${VIRTUALENVHOME}/bin/activate && ${PROJECTROOT}/manage.py runserver 0:8000
This is pretty much how it's done with Fabric, Ansible and any other automation tool.
edit: of course you'd be supplying the values for the variables VIRTUALENVHOME and PROJECTROOT