I saw some waterfall display for buildbot which have builds and tests categorized by device types. How do I get this type of display. Does buildbot automatically generate different columns for different slaves? Right now I am using only one slave and handling the scheduling of tests with python script. Is it possible to use only buildbot slaves to achieve the parallel tests?
In waterfall page you buildbot generates a columns per builder. You can add and configure builders in master.cfg file. Have a look at this for more info.
You can achive parallel builds by adding multiple builders to your slave, and in slave configuration increasing max_builds parameter like`
config['slaves'].append(BuildSlave('my-slave', 'password', max_builds=5))
This will allow you to run 5 builds in parallel for example.
Related
I have a multiple services project which is deployed into kubernetes clusters. Currently we're trying to cover our frontend with Cypress tests. We're executing tests on our CI pipeline in Azure DEVOPS.
The main problem is to keep tests flow consistent as every test is able to change the test data. The ideal solution (what I see) would be to make them isolated by resetting database (loading data from dump) between test suites or even single tests. It works fine locally however in CI env seems to be not feasible - it also needs to reset cache (redis and memcached) and loading dump itself takes several minutes per time.
Would love if you can share your best experience and thoughts about that.
Thanks in advance!
I am actually using circle ci to launch my behat tests through docker.
I want to migrate to github actions for cost reasons but i can't find any clue on how i can split my files on github actions when using parallel build.
Here is the command i am using to split my files on circleCI: circleci tests glob "features/**/*.feature" | circleci tests split --split-by=filesize.
Is there any existing command to do it appart from using knapsack pro which i can't use.
Thanks!
Try using split_tests, a tool similar to circleci tests glob.
It has the same set of features: split files according to filename, lines count or timing of a previous test result.
You'll probably need to configure your Github-Actions ci.yml to:
Download a binary release of split_tests
Create a matrix with a number of nodes,
For each node, run the tests using the split_tests partial files list,
(Optionally) Save the JUnit test report to a cache, to re-use it in the next run for timing.
This question concerns use of the Jenkins Workflow plugin and "synchronizing" a stage amongst independent jobs.
We have a generic workflow for multiple projects with steps:
build project
push project to test environment
run (long) end-to-end test suite
push project to production
Step 3 runs a long time. If multiple projects are built and pushed to the test environment within the same window of time, we'd like to only run once the end-to-end test suite.
Can we have the jobs some how synchronize on step 3?
The desired orchestration can be achieved by make Step 3 a build action. I.e.
build end-to-end-tests
Where end-to-end-tests is a job dedicated to running the slow end-to-end tests.
Adding a Quiet period to end-to-end-tests supports the goal of "collecting" projects updated within a time period to end-to-end test. That is, if project A and B are pushed to the test environment with Quiet period seconds, then end-to-end-tests runs only once.
JENKINS-30269 might be helpful, but your use case is indeed subtly different from the usual one that RFE would solve; you really seem to need a cross-job stage, which is not currently possible though in principle such a step could be written. In the meantime, a downstream deployment job is probably the most reasonable workaround.
I have downloaded the TCB plugin for Jenkins. I have several builds that run tests. These builds must be run individually, as they access similar files that can cause tests to fail if more than one test build is running. I have been trying to find the place where I put the builds into a "category", so I can throttle the whole test category down to 1/1. I thought that it might be the Jenkins Views, but that did not do the job. How do you add jobs to a category?
This tag discusses the solution I desire: Jenkins: group jobs and limit build processors for this group. The only problem is that it doesn't say how to add them to categories.
You set up categories in the global Jenkins configuration (Manage Jenkins -> Configure System) and then assign jobs to categories. See the "Per Project-Category" section in the plugin documentation.
I've been looking into buildbot lately, and the lack of good documentation and sample configurations makes it hard to understand how buildbot is commonly used.
According to the buildbot manual, each buildmaster is responsible for 1 code base. That means that a company that wants to use buildbot on, say, 10 projects, needs to maintain 10 different sets of buildbot installations (master-slaves configurations, open ports, websites with output etc.). Is this really the way things are done? Am I missing an option that creates a mash-up that is easy to maintain and monitor?
Thanks!
At my place of work we use Buildbot to test a single program over several architectures and versions of Python. I use one build master to oversee about 16 slaves. Each set of slaves pulls from a different repo and tests it against Python 2.X.
From my experience, it would be easy to configure a single build master to run a mash-up of projects. This might not be a good idea because the waterfall page (where the build slaves report results) can get very congested with more than a few slaves. If you are comfortable scrolling through a long waterfall page, then this will not be an issue.
EDIT:
The update command in master.cfg:
test_python26_linux.addStep(ShellCommand, name = "update pygr",
command = ["/u/opierce/PygrBuildBot/update.sh","000-buildbot","ctb"], workdir=".")
000-buildbot and ctb are additional parameters to specify which branch and repo to pull from to get the information. The script update.sh is something I wrote to avoid an unrelated git problem. If you wanted to run different projects, you could write something like:
builder1.addStep(ShellCommand, name = "update project 1",
command = ["git","pull","git://github.com/your_id/project1.git"], workdir=".")
(the rest of builder1 steps)
builder2.addStep(ShellCommand, name = "update project 2",
command = ["git","pull","git://github.com/your_id/project2.git"], workdir=".")
(the rest of builder2 steps)
The two projects don't have to be related. Buildbot creates a directory for each builder and runs all the steps in that directory.
FYI, BuildBot 0.8.x supports several repositories on one master, simplifying things a bit.