Skip to main content

continuous integration with buildbot 간략 설정

git, svn등, 소스관리 툴을 사용하다 보니, 다수의 사용자에 의해서 소스가 관리된다.
그러나, 어느 누군가가 소스서버에 commit or push할때, 뭔가 빠뜨리는 경우가 발생한다.
분명, 그 어느 누군가의 환경에서는 컴파일이 되나, 다른 사용자가 소스서버에서 fetch한 소스는 컴파일이 되지 않을 것 이다.

이런 경우를 사전에 회피하기 위해, continuous integration tool이 사용된다.

 그 중, 본인은 buildbot를 사용해 보았다.

기본적인 buildbot의 정보는 아래의 사이트에서 구한다.





완성된 master.cfg


c = BuildmasterConfig = {}
####### BUILDSLAVES
# The 'slaves' list defines the set of recognized buildslaves. Each element is
# a BuildSlave object, specifying a username and password.  The same username and
# password must be configured on the slave.
from buildbot.buildslave import BuildSlave
['slaves'] = [BuildSlave("아무개", "아무개암호")]


c['slavePortnum'] = 9989

from buildbot.changes.gitpoller import GitPoller
from buildbot.changes.pb import PBChangeSource

c['change_source'] = PBChangeSource()

#master.cfg.sample에서는 GitPoller를 사용하고 있으나, 잘 안 되더라...
#GIT repository가 갱신이 되어도, 잘 안 되고.
#force build는 잘 되던데... 여하튼
#본인 PBChangeSource 클래스를 사용했음.

####### SCHEDULERS
# Configure the Schedulers, which decide how to react to incoming changes.  In this
# case, just kick off a 'runtests' build

from buildbot.scheduler import Scheduler, Periodic
c['schedulers'] = []

# 매 2시간마다 컴파일 하도록 했다.
c['schedulers'].append(Periodic(name="20 minutes build scheduler",
             builderNames=["mediamanager1"],
            periodicBuildTimer=2*60))

from buildbot.process.factory import BuildFactory
from buildbot.steps.source import Git
from buildbot.steps.shell import ShellCommand


factory1 = BuildFactory()
factory1.addStep(Git(repourl='file:///git/mediaserver/appl.git', mode='update'))
factory1.addStep(ShellCommand(command=["make"], workdir="build"))


from buildbot.config import BuilderConfig

c['builders'] = []
c['builders'].append(
    BuilderConfig(name="mediamanager1",
       slavenames=["아무개"],
       factory=factory1))



c['status'] = []

from buildbot.status import html
from buildbot.status.web import auth, authz
authz_cfg=authz.Authz(

    gracefulShutdown = False,
     forceBuild = True, # use this to test your slave once it is set up
     forceAllBuilds = False,
     pingBuilder = False,
    stopBuild = False,
    stopAllBuilds = False,
     cancelPendingBuild = False,
)

c['status'].append(html.WebStatus(http_port=8010, authz=authz_cfg))



c['projectName'] = "원하는 대로"
c['projectURL'] = "Trac이나 wiki주소등.."

c['buildbotURL'] = "http://localhost:8010/"

c['db_url'] = "sqlite:///state.sqlite"

Comments

Popular posts from this blog

Linux Resources Monitoring

dstat Requirements:python Dstat is a versatile replacement for iostat, vmstat and ifstat http://linux.softpedia.com/get/System/Diagnostics/Dstat-1401.shtml  - download the source file  - tar -xvjf dstate-0.7.2.tar.bz2  - cd dstate-0.7.2  - sudo make install 사용법 dstat -cdngys --top-io-adv --top-bio-adv 창넓이가 크면 dstat -cdngys --top-io --top-bio dstat 기본옵션은 -cdngy 2. pktstat requirements: libpcap-devel, ncurses-devel pktstat man page 사용법:sudo pktstat -i eth0 -T -l 실행결과 interface: eth0    total: 43.9Mb (3s) cur: 12.3M (78%) min: 12.3M max: 15.8M avg: 14.5M bps    bps    %      b desc   1.4k   0%   4.3k arp  591.8   0%   1.2k ip proto 88 55.101.66.3 <-> igrp-routers  91.3k   0%  91.3k tcp a100236:4478 <-> console:ssh  42.6k   0% 216.4k tcp a100390:mailprox <-> console:ssh   1.1k   0%   ...

nginx로 다중 포트 설정 및 다중 react app 설정

nginx에 다중 포트 설정하기 react로 여러 webapp를 개발하고, 동일한 서버에 실행시킬 필요가 있다. 이때 간단히 nginx에서 다중포트로 여러 webapp를 동일한 서버에서 실행시킬 수 있다. /etc/nginx/sites-available/에 default 파일이 있다. 보통 port 80로 설정되어 있다. 이 파일을 복사해서 sub로 명명한다.   아래와 같이 포트 8080으로 정하고, react app를 build한 디렉터리를 root <dir>로 지정하고, $> sudo service nginx restart 하면 된다. $>sudo systemctl status nginx.service 로 nginx 상태 확인이 가능하면, $> netstat -ano | grep 8080 으로 8080 포트가 살아있는 또는 외부PC에서  $>telnet ip 8080으로 telnet 접속이 되는지 확인하면 된다. 종종 Nginx 500 Interval Server Error가 발생하는데, 이는 1) root <dir>에서 <dir> 주소가 정확하지 않거나, 2) 파일 권한이 없거나이다. chmod 755 <dir>하면 대부분 해결될 것이다. 그럼 오늘도 유익한 하루 되시길..   

SDN(OpenFlow) 개요

OpenFlow는 SDN(Software Defined Network)의 하나의 콤포넌트이다. 아래는 2013/3/13 오픈프로우 코리아 주최로 열린 한국 SDN Interest Group 4번째 정기세미나의 내용이다. 다음에는 꼭 모임에 참석하고 싶다. SDN Architecture including OpenFlow 위 그림에서와 같이, Control Layer부분과 Application Layer부분이 최근 활발히 연구개발되고 있다. 그 중 Control Layer부분은 Controller가 많은 비중을 차지 하는데, 다음 절에서와 같이 이미 많은 벤더들이 많은 OpenFlow 기반의 Controller를 제공하고 있다. 그외 소규모 벤더들은 Controller가 아닌 Application Layer에서 보안, 로드벨런싱, 홈네트워크 등의 서비스가 지원되는 제품 개발에 힘쓰고 있다. SDN에서는 Router라는 명칭 대신, Switch라는 명칭을 사용하는데, 이는 Router보다 더 단순한 기능을 수행하고, 기존 레거시와 차별화를 위해 명명된 것으로 보인다. 또한, Switch를 반드시 벤더로부터 구매할 필요가 없다. 상황에 따라 리눅스 등의 운영체제를 기반으로 자체 개발이 가능하다. Controllers의 종류 SDN의 Controller 가운데 Open Source로 운영되는 것은 다음과 같다. 대부분 Java언어로 구현되어 있다. 따라서 플랫폼 또는 인프라 개발자라면 Java에 능숙해야 한다. NOX C++/Python Beacon Java Floodlight Java Maestro Java RouteFlow NOX, Quagga 보안을 위한 Open Source FortNOX Java 기반의 SE-FloodLight  공격 감지  인증  스위치의 Flow 처리 성능 고려 FRESCO OpenFlow Contro...