GitLab

This is actually the way we run our instance.

Add a "make deploy" target which applies the deployment with newer image and
trigger a rolling-release.

Otherwise our registry (harbor) fail to regonize the digests are already
present... This is weird.

Prune debian directory but keep docker related files since its referenced from
README.rst which is shipped in sdist

Since it's rst file

The files are never present in /etc/cubicweb.d/intranet/i18n because
"db-create" does not run here.

This ensure i18n catalogs are up-to-date.

/etc/cubicweb.d/intranet/data is never present at docker startup, so the test is useless.

Since we now install /src in editable mode, just mounting the source in /src is
enough to have a working "dev" environment.

Move "hints" command to the README.

Also install setuptools from debian package since the setuptools version is now
high enough to install Markdown, see previous changeset "Drop use of pipenv".

flake8 doesn't require the source to be installed

This is no longer useful with related cubes being released for py3 & new style cube.

See https://lists.cubicweb.org/pipermail/cubicweb-devel/2019-May/002818.html
I think pipenv will add maintance cost we don't need here.

Install additional requirements from docker/requirements.txt file.
Install cubicweb-intranet in editable mode in /src
Install setuptools with pip because the version in stretch doesn't work with the latest Markdown version :/

This allow to develop cubicweb-intranet with docker.

make dev will:

* build image
* run a container with code mounted in /src
* install cubicweb-intranet in editable (develop) mode from /src
* spawn an interactive shell in the container

It mean we can edit the source code locally and run/test it in the container.

This help to run the image using a local postgresql server with peer authentication through unix socket (for testing).

The makefile is used to run various commands related to docker (build, push).

* install dependencies with pipenv (so we can control upgrades and have a reproductible build).
* install current source code for cubicweb-intranet
* handle instance creation with pyramid.ini with redis sessions
* handle database upgrades

We use cubicweb-bootstrap in our instance and this conflict with
cubicweb-bootstrap.

The file uiprops.py was manually dropped from our production instance.
So I think we can drop this.

I don't know why it was added but we don't have any Repository entity in our
instance. So just drop it.

Keep the depencency since we can't run "drop_cube()" without having the cube
installed...

They exist in our instance of intranet, if we want to drop them we have to
write a migration.

All dependencies (not yet released) should be py3 compatible and using the new layout.

* In tox, pull latest public head of each cubicweb cubes dependencies
* Update imports from "cubes.<cube>" to "cubicweb_<cube>"

- remove useless test files and add basic tox.ini file
- add basic README file
- update min versions for Cubicweb & File cube

- move files to cube folder
- update setup.py, MANIFEST.in, cubicweb_intranet/__pkginfo__.py
- remove __pkginfo__.py

--HG--
branch : stable