Is there any way to programmatically check say, using the GitHub API or some API for Travis CI, if a particular project on GitHub or Travis CI uses SonarQube?
Also apart from SonarQube what other program analysis tools do people usually use?
Neither GitHub API nor Travis CI API will be able to provide you with such information - simply because code analysis tools/services are third-party systems that are not built-in features of GitHub or Travis CI.
If you want to "see how many open source projects on GitHub use static program analysis tools", then you would have to browse the source code of each repository to discover some facts that might give you this information (like for instance looking into the .travis.yml file). But because there's no built-in/standard feature on that topic, this would be extremely difficult to correctly achieve this goal IMO.
Related
I am trying to integrate Percy.io, a visual regression testing tool with Github status check.
I have signed up for free account with Percy and paid Github version.
I wanted to setup status check with Percy with each pull request as below suggested at percy doc on status check
I have integrated Percy in Github
Added rules in Github
but still don't see check on pull request.
Added same project in percy.io too
Any Idea what I am missing over here?
It's hard to be specific without knowing more about your application, however one piece that seems to be missing from your setup is a CI/CD configuration.
Basically, you need a Continuous Integration service (such as Travis, Jenkins, CircleCI or others to trigger a build for your project so that percy can capture snapshots. Did you configure one?
See the documentation here.
Here an example configuration for one of my projects. Note that how you set this up may differ if you use a different set of tools than what's in the article.
Is there any service / feature of github.com just like Bitbucket Pipeline ?
I'm actually want to push my master branch to FTP server (cpanel, apache) . It's really easy with Bitbucket Pipeline, but any way to do that in Github ?
Github now has a feature called Github Actions, which allows you to execute arbitrary commands and processes triggered by events such as repository writes, pull request merges, and others similar to Bitbucket Pipelines. So your build/test/deploy stages can be run using Github's infrastructure, or you can move your app code to a remote location such as an FTP server, to kick off a code pipeline or update remote artifacts.
GitHub itself doesn't provide this feature, but you can use GitHub apps, such as Travis CI.
Travis CI enables your team to test and ship your apps with confidence. It’s built for everyone and for projects and teams of all sizes, supporting over 20 different languages out of the box, including Javascript and Node.js, Ruby, PHP, Python, Mac/iOS, as well as Docker, while giving you full control over the build environment to customize it to your own needs.
There is also other apps for continuous integration: https://github.com/marketplace/category/continuous-integration
Not that I know of. You could however setup an internal build server using jenkins, circle ci, or travis ci. I have used both jenkins and circle ci both integrate well with github(It's fairly straight forward process). Jenkins is open source, where as circle ci is cloud base solution(it has a free tier). Both I believe could help solve your issue.
GitHub announced an upcoming feature, GitHub Actions.
I'm positive on the benefits of CI tools like Jenkins for automatic building or testing, which GitHub Actions is aimed to be used for in the future.
Having a repository on GitHub and using an external CI tool has the huge benefit of allowing to move the repository to another Git repository platform (or even local) without rewriting of the whole CI process. With GitHub Actions, you're more or less tied to the GitHub ecosystem.
I assume the integration of GitHub's Actions will be more fluent in the native environment, but are there any other advantages or disadvantages besides that?
I've been working with GitHub actions full time for a couple of months now.
It's still early days (June 2019), but here's my list:
Advantages:
GitHub actions are just consecutive docker runs. Very easy to reason about and debug.
Reproducing the build environment for container-based Travis is
possible,
but more difficult.
On GitHub actions it's just a docker build docker run away.
The individual actions in a workflow are isolated by default.
You can use a completely different computing environment for, say, compilation and testing.
Travis CI (and I think other "traditional" CI) would run all "stages" (~ actions) in the same computing environment.
Again, GitHub actions are much easier to reason about and debug.
The main.workflow spec (a subset of the HCL and really just a directed acyclic graph) is open source.
The whole thing is a pretty thin wrapper around Docker anyway, so platform lock-in is arguably minimal.
There are already open-source reimplementations of GitHub actions, such as act for local testing.
You have ready access to the GitHub API with (somewhat limited) authentication out of the box.
There might be a vibrant community (marketplace?) where people can share actions.
For example, I'm reusing deploy actions build by different people in different ecosystems.
A directed acyclic graph (DAG) and the visual editor for main.workflows is perhaps a good way to model CI/CD in particular and workflows in general.
Takes some getting used to, but generalises well.
GitHub actions can do a whole lot more than just CI! You've got basically the whole API at your fingertips as inputs and outputs.
Disadvantages:
GitHub actions (still?) has sometimes surprisingly foundational limitations at this point (june 2019).
No native caching.
You get image and layer caching (it's complicated), but nothing else.
For build artefacts, you have to roll your own cache (via AWS, Azure, etc. ...), which can be a lot of work. (You can see a hacky setup here.
Surprisingly, no support for pull requests from forks.
It's again a bit complicated, and understandable from a security standpoint, but it's currently not possible to run actions a) against the secrets of the receiving repo of a fork PR (base), and/or b) against the would-be merge result of a fork PR (that's what travis does).
For a workflow that involves forks, that makes GitHub actions largely unuseable as CI/CD tool.
Single platform, it's just whatever you can run inside docker, so some Linux distro. That seems unlikely to change, but might be an acceptable limitation.
You can always add an action to call other cross-platfrom CI/CD services.
The documentation is still pretty sparse.
Not much in the way of best practices or scaffolding.
The quality and breadth of published GitHub actions (at least on the marketplace) is still pretty low / limited.
We'll see whether that takes off.
No great way to unit-test actions. (I hacked something together, but I'm not too sure about it).
Having a repository on GitHub and using an external CI tool has the huge benefit of allowing to move the repository to another Git repository platform (or even local) without rewriting of the whole CI process.
With GitHub Actions, you're more or less tied to the GitHub ecosystem.
Yes, and starting November 2019, slightly less so:
See Joe Bourne's annoucement "Self-hosted runners for GitHub Actions is now in beta".
You can have self-hosted runners, which means:
Your environment, your tools,
Any size machine or configuration,
Secure access and networking,
Large workload support.
To support using self-hosted runners in your workflows, we’ve expanded the experience of using the runs-on key.
When registering your self-hosted runners, they’re each given a read-only label self-hosted which you can use with runs-on.
Here’s an example:
# Use Any available Self-hosted runners connected to repo
runs-on: self-hosted
See the documentation at "Hosting your own runners".
I am developing a small python web service with bunch of analytical codes and searching for a lightweighted, easy-use but all-around Continuous Integration tool to use together with github.
I push my code onto github and hope that by every pushing continuous integration can run tests and check the integreity
some recommended tools from github website https://github.com/integrations
like cloudBees, circleci etc.
Which kinds of CI tools is best for me at this moment ? thanks a lot
And would be kind if you could give some tips/good tutorials on coutinuous workflow(development and deployment) with github and docker
Like Jake said I would say that a cloud based tool like SnapCI, Circle or Travis would work well for you as you are already hosting your source in the cloud. If you are working on a public repo many of these tools are free.
In order to help with Docker and Github you'd need to be more specific about your needs.
I am trying to create the following workflow for continuous integration on my project
Developer commits code change to Github
Github sends entire codebase to Travis CI
Travis CI does the following
Runs tests
Builds distribution worthy package, saves in filesystem location local to Travis CI
Deploys distribution worthy package to Nodejitsu
Nodejitsu restarts server with the distribution worthy package
Is this possible? What are the steps? Via Github webhooks, I do have Travis CI running tests, and Nodejitsu deploying (untested and distribution worthy) Github codebase, but I do not have the workflow described above. Am I expecting something that is not possible?
Thank you!
This is possible, and how we deploy many of our systems internally.
For a quick getting started guide please try:
https://www.nodejitsu.com/getting-started-with-github
Detailed documentation can be found here:
https://www.nodejitsu.com/documentation/features/webhooks/
If you have any other questions, feel free to reach out to Nodejitsu support.