BadgeApp

Normally only a single version of the product is in production use. That said, it's important to handle upgrades, especially so that various developers can upgrade. How to upgrade is documented in CONTRIBUTING.md.

Here is a summary of common cases: * Upgrading often involves a database migration, which is handled by running "rake db:migration" (if the user forgets to do this, it is detected, running stops, and this information is presented). * Other upgrades generally involve installing updated gems (libraries), which are handled with "bundle update". * In rare cases an update to the Ruby language is needed; the steps to do this are also in CONTRIBUTING.md.

Yes, GitHub issue tracker.

We've never had an external bug reporter.

CONTRIBUTING.md notes that:

We will gladly give credit to anyone who reports a vulnerability so that we can fix it. If you want to remain anonymous or pseudonymous instead, please let us know that; we will gladly respect your wishes.

This is emphasized in the vulnerability report handling process docs/security.md, where the last step is giving credit.

The vulnerability report handling process is documented in docs/security.md.

CONTRIBUTING.md documents our coding style guides.

As documented there: * For Ruby on Rails, we generally follow the community Ruby style guide and the complementary community Rails style guide. * For JavaScript, our coding style is based on the Node.js style guide.

CONTRIBUTING.md documents our coding style enforcement mechanisms.

As documented there: * For Ruby on Rails, we use rubocop and rails_best_practices for style enforcement (as well as Brakeman to find vulnerabilities) * For JavaScript, we ESLint.

The application does not create native binaries. (Some of the libraries it depends on do, but those are external.)

The application does not create native binaries. (Some of the libraries it depends on do, but those are external.)

The application does not create native binaries. (Some of the libraries it depends on do, but those are external.)

The application does not create native binaries. (Some of the libraries it depends on do, but those are external.) It is written in scripting languages where the source code is used directly.

We include an install script, install_badge_dev_env which allows devs to quickly install the software for development. This script uses calls to various package managers to install all necessary dependencies quickly and easily. The uninstall process is documented in docs/INSTALL.md.

There is no installation system for build artifacts, as it's written using scripts.

It could be said that Rails builds web application assets (e.g., minified and concatenated JavaScript, and combined CSS); under that interpretation, they are written by the Rails framework as part of the execution of the Rails asset pipeline, and this is controlled in the usual way by controlling the framework.

The software is installed using standard conventions for this kind of software. The underlying Ruby libraries are installed using bundler (the usual Ruby package manager). Lower-level system components are normally installed using the system package manager.

It's possible to install these quickly, using a provided installation shell script that determines which system package manager to use & tries to automatically install whatever is needed, including the tests and test environment. The instructions for quickly installing everything is in INSTALL.md.

External dependencies are stored in a Gemfile.

External dependency checking is performed in two ways:

• bundle_audit. This checks all gems for known vulnerabilities. This is run on every execution of the "rake" local check task and on every run of the continuous integration task on CircleCI.
• Gemnasium. This also checks gems for known vulnerabilities, and puts the current status on a badge that is displayed on the front page of the project home page.

For the few external dependencies that aren't managed as gems (e.g., PostgreSQL) the system package managers and/or the deployment system's managers are used to maintain them & periodically check them.

The project uses bundler, the standard package management solution for Ruby, for most externally-maintained components. For the rest (e.g., PostgreSQL) it uses the system package manager.

We avoid depending on deprecated/obsolete functions.

We use CircleCI to automatically test every check in to any branch in our repository. I some circumstances experimental branches which do not yet run even in a development environment may be ignored via a custom entry in our circle.yml file. The master, staging, and production branches are always tested.

When regressions occur, we add tests for them.

As of this writing, we have 100% statement coverage, see Codecov.io.

Yes, this is a documented policy in CONTRIBUTING.md which says:

When adding or changing functionality, please include new tests for them as part of your contribution.

Yes. The CONTRIBUTING file at https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/CONTRIBUTING.md says, "When adding or changing functionality, please include new tests for them as part of your contribution".

The settings for the warning tools are generally fairly strict.

They are implemented, as described in docs/security.md.