GitLab

Bug fix: OAuth2 registration

See merge request !47

refactor django db init

See merge request !45

(not working if 'fig' is implemented as a shell alias)

In the current initialization process (i.e. the SQL migration script),
the site ID value must be set at 4. It can be changed of course in the
administration and updating the `ALLGO_SITE_ID` environment variable
accordingly.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

For the Oauth registration of the Django-Allauth plugin, I was at first
requiring an email verification for local signup. It's not compatible
with Oauth registration. I removed this parameter. After some tests, if
a mail server is configured then, a verification email a sent to the
user signing up locally.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

handle webapp version selection in the job views

Closes #180

See merge request !49

An error was raise when creating a job related to `Exception Value: type
object 'WebappVersion' has no attribute 'COMMITTED'`. The issue was the
misspelling in the model (missing a 't' at "committed"). This commit fix
this issue.

Resolves: #180

Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

The Oauth registration was buggy for several reasons. The links used in the templates were the wrong one inhibiting the correct behaviour.
The site ID configuration was wrong. This part is fixed by updating the migration script. The current system needs at least to have the `ALLGO_SITE_ID`
set up corresponding to the actual URL of the website (http://localhost:<PORT> in development https://allgo.inria.fr in production.
The `ACCOUNT_USERNAME_VALIDATORS` was raising an error on the Oauth registration and has been removed. No known bug were introduced by doing that.

The login and signup templates have been rewritten in order to have a smoother and nicer integration in the current website. Moreover, the
focus has been made on the OAuth registration (that's what users see first).

The user admin part has been modified in order to display the possibility to change the password in case the user has set up a local account on the service
or the management of its Oauth connections (redirecting to the `connextions.html` template provided by the django Oauth plugin and integrated in the website.

This commit will have to be reverted when we go to production

This commit removes the calls to the 'migration.sh' script that
did a full a import of the rails db (rails apps will be imported
on-demand)

The django db is now initialised from scratch, using the db_seed command

This adds the 'db_seed' management command (python3 manage.py db_seed)
for automatically seeding the db with default entries.

- initial docker OS list (debian, centos, fedora, ubuntu)
- default job queue (named 'default')
- the 'inria' Group

Additionally, in the dev setup, it creats 3 users (all with
password 'allgo'):
- admin@localhost which is superuser
- devel@localhost which own a webapp named 'sleep'
- guest@localhost

(to be regenerated before the first deployment in production)

mentionned by !41

Registry integration

See merge request !42

manage the evaluation of permissions in the model

See merge request !41

fix docker image name comparison

See merge request !40

registry integration with the reverse-proxy

See merge request !37

(so that a default registry configuration is provided with the image)

(and have it  generated by the container_init script)

`docker_name` is *not* the same as `name.lower()`

migrations are now in the sources
(and the sources are read-only in production anyway)

no longer needed

no longer needed because registry and django are now share the same
host name

- images manifest push/pull are routed through the django server
- all other endpoints are routed directly to the registry


On client-side the registry url is the is the same as the allgo server.
The backend registry location is configured by the
ALLGO_REGISTRY_PRIVATE_URL which is set to "http://{ENV}-registry"
by default (i.e. 'http://dev-registry' in dev)


Because the registry URL is configured at runtime (by the env
var), the nginx config can no longer be static.
/etc/nginc/conf.d/allgo.conf is generated at runtime
 (after loading the django config)

now the server root is routed directly to the django container