开源软件名称：

开源软件地址：

开源编程语言：

开源软件介绍：

Remote Settings

Remote Settings is a Mozilla service that makes it easy to manage evergreen settings data in Firefox. A simple API is available in Firefox for accessing the synchronized data.

https://remote-settings.readthedocs.io

Content

This Remote Settings repository contains the following:

• bin/: container entry point and script(s)
• config/: example configuration file(s)
• docs/: documentation source files
• kinto-remote-settings/: Kinto plugin specific to Remote Settings
• tests/: browser and integration tests
• requirements.in: Python packages for the service (source of truth for requirements.txt)
• requirements-dev.txt: Python packages for local development and tests
• VERSION: SemVer version number that serves as both the version of the service and the kinto-remote-settings plugin

Run

You need Docker and docker-compose. Ensure buildkit is enabled on your Docker engine.

make start

Your Remote Settings instance is now ready at http://localhost:8888. See the *Setup a Local Server* tutorial for more details.

Test Locally

Kinto Remote Settings Unit Tests

To run unit tests, you need Postgres installed and a database testdb available. This can be created with:

make build-db

After this setup is complete, tests can be run with pytest using make:

make test

Integration & Browser Tests

With Docker and docker-compose, test that all components are working as expected with:

make build
make integration-test
make browser-test

That will start memcached, postgresql, autograph and Kinto (at web:8888) and lastly the tests container that primarily uses pytest to test various things against http://web:8888/v1.

When you're done running the above command, the individual servers will still be running and occupying those ports on your local network. When you're finished, run:

make stop

Test Remote Server

Integration tests can be executed on a remote server.

docker-compose build tests

docker-compose run \
    --env SERVER=https://settings.dev.mozaws.net/v1 \
    --env MAIL_DIR="" `# disable tests about emails.` \
    --env SKIP_SERVER_SETUP=true \
    --env EDITOR_AUTH=editor:azerty123 \
    --env REVIEWER_AUTH=reviwer:s3cr3t \
    tests integration-test

Debugging Locally (simple)

The simplest form of debugging is to run a suite of tests against the kinto server:

make integration-test
make browser-test

Debugging Locally (advanced)

Suppose you want to play with running the Kinto server, then go into a bash session like this:

docker-compose run --service-ports --user 0 web bash

Now you're root so you can do things like apt-get update && apt-get install jed to install tools and editors. Also, because of the --service-ports if you do start a Kinto server on :8888 it will be exposed from the host.

For example, instead of starting Kinto with uwsgi you can start it manually with kinto start:

kinto start --ini config/local.ini

Another thing you might want to debug is the tests container that tests against the Kinto server.

docker-compose run tests bash

Now, from that bash session you can reach the other services like:

curl http://autograph:8000/__heartbeat__
curl http://web:8888/v1/__heartbeat__

Upgrade Things

Most common use-case is that you want to upgrade one of the dependencies.

Top level dependencies are listed in requirements.in.

We use pip-tools's pip-compile command to generate the exhaustive list of pinned dependencies with their hash.

To upgrade a single package, run:

pip-compile --upgrade-package kinto-attachment

To test that this installs run:

docker-compose build web

About versioning

We respect SemVer here. However, the "public API" of this package is not the user-facing API of the service itself, but is considered to be the set of configuration and services that this package and its dependencies use. Accordingly, follow these rules:

• MAJOR must be incremented if a change on configuration, system, or third-party service is required, or if any of the dependencies has a major increment
• MINOR must be incremented if any of the dependencies has a minor increment
• PATCH must be incremented if no major nor minor increment is necessary.

In other words, minor and patch versions are uncomplicated and can be deployed automatically, and major releases are very likely to require specific actions somewhere in the architecture.

Releasing

First:

• Make sure the CHANGELOG is up-to-date and includes details about all the components included in the release

git checkout -b prepare-X.Y.Z
prerelease

• At this point, the CHANGELOG.rst header and version number in VERSION are set.

git commit -a --amend
git push

• Open a PR, and when the PR is approved:

git checkout main
git pull
git tag -a X.Y.Z
git push origin X.Y.Z

• Now prepare the next version:

git checkout -b start-X.Y.Z
git push

• Draft a release on Github: https://github.com/mozilla/remote-settings/releases For release notes, just use the CHANGELOG entry for the release, but change all the ReST-style section headings to Markdown-style ## headings.