-
Updated
Aug 31, 2020 - Go
Continuous integration
Automatically build and test your code as you push it upstream, preventing bugs from being deployed to production. A complementary practice to CI is that before submitting work, each programmer must do a complete build and run (and pass) all unit tests. Integration tests are usually run automatically on a CI server when it detects a new commit.
Here are 2,226 public repositories matching this topic...
-
Updated
Sep 4, 2020 - Java
-
Updated
Jan 27, 2020 - JavaScript
-
Updated
Sep 4, 2020 - Go
-
Updated
Sep 4, 2020 - Java
-
Updated
Aug 21, 2020 - JavaScript
JanitorConfigurator should have an option to delete logs for specific builders (or tags). Users might want to delete logs for only specific builders, or might want to keep logs for specific builders for longer duration.
http://docs.buildbot.net/latest/manual/cfg-configurators.html#janitorconfigurator currently doesn't seems to contain any such option.
We are using font-awesome V4 and should migrate to font-awesome V5 which comes with its own vue.js module: https://github.com/FortAwesome/vue-fontawesome
Migration includes removing old font-awesome V4 module and changing all existing icons to new vue.js tag.
This is blocked until #114 is merged which comes with first initial integration.
Summary
jx create addon istio doesn't work
since v 1.5 istio moved to operator so no folder install/kubernetes/helm/istio
Steps to reproduce the behavior
jx create addon istio
Output
Istio package already downloaded: /Users/msirs/.jx/cache/istio-1.6.0-osx.tar.gz
error: Could not find folder install/kubernetes/helm/istio inside istio clone at /Users/msirs/.jx/cache/istio
-
Updated
Aug 27, 2020 - JavaScript
-
Updated
Aug 29, 2020 - Java
-
Updated
Sep 4, 2020 - Go
Opencover allows hiding skipped modules by providing a `hideskipped parameter. Would be great to add this.
See https://github.com/OpenCover/opencover/wiki/Usage#console-application-usage for details.
-
Updated
Jun 11, 2020 - PHP
-
Updated
Aug 12, 2020
-
Updated
Sep 4, 2020 - Go
-
Updated
Sep 1, 2020 - Python
-
Updated
Aug 18, 2020 - Ruby
-
Updated
Nov 5, 2018
-
Updated
Sep 4, 2020 - Go
-
Updated
Aug 6, 2020 - Go
-
Updated
Sep 2, 2020 - CMake
-
Updated
Aug 29, 2020 - JavaScript
-
Updated
Dec 31, 2019 - PHP
-
Updated
Aug 10, 2020 - Shell
-
Updated
Aug 18, 2020 - PHP
-
Updated
Sep 3, 2020 - TypeScript
-
Updated
Sep 4, 2020 - Go
- Wikipedia
- Wikipedia
Continuous integration apps
CircleCI
Automatically build, test, and deploy your project in minutes
Hound
Automated code reviews
Cloud 66 Skycap
Skycap is a container native CI/CD tool
Codefresh
A modern container-based CI/CD platform, easily assemble and run pipelines with high performance
Google Cloud Build
Build, test, & deploy in a fast, consistent, and secure manner
AppVeyor
Cloud service for building, testing and deploying Windows apps
BuildPulse
Automatically detect, track, and rank flaky tests so you can regain trust in your test suite
CloudBees CodeShip
Continuous Integration and Delivery. Fast. Customizable. Easy
Cirrus CI
Enjoy unlimited concurrency for fast and secure development cycle
WhiteSource Bolt
Detect open source vulnerabilities in real time with suggested fixes for quick remediation
Flaptastic
Manage flaky unit tests. Click a checkbox to instantly disable any test on all branches. Works with your current test suite
Cloud 66 for Rails
Build, deploy, and maintain your Rails apps on any cloud or server
App Center
Continuously build, test, release, and monitor apps for every platform
GuardRails
GuardRails provides continuous security feedback for modern development teams
Travis CI
Test and deploy with confidence
When viewing a build that reconfigures pipelines, it's hard to tell which pipelines were actually changed:
Quick suggestion: highlight it in yellow, like the
getstep? Or the opposite - dim steps which had no changes to apply? No strong preference!This would likely involve emittin