sci-oer / webapp Goto Github PK

This api should support polling to check if a has been completed or not.

• should be a GET request GET /api/build/{id}
• requires authentication
• should return 202 if it is not yet complete, the body should include some information about the progress
• should return 201 if the build completed, information about the build should be included in the response body
• should return 410 if the build failed, the body should include the reason why the build failed

The contents of the response body should be discussed here before implementation begins.

For local development and testing having a docker compose file that will run the webapp and its required other services should be added.

• should build the webapp container
• should run the database
• should run an authentication provider service (oauth2 or saml)
• other sidecar / sister services

The landing page must have:

most of these features should be included as a base template file so that it can be included in every page without being hard coded into each.

• about the sci-oer project (content can be mocked for now)
• navigation bar to other pages
  • create an image
  • login
  • administration (conditional)
  • for students
  • for instructors
  • publications
• footer that contains
  • license
  • copyright info
  • link to source
  • other info

This is the endpoint that will be called to create a new custom course container.

It must:

• require authorization (must be logged in + have a permission that allows the creation of containers)
• must be a POST API call (it is not safe and not idempotent)
• Should return 202 Accepted the response body that includes an build ID to poll the status of the build. (the build ID can also be used by a websocket interface to subscribe to receive updates on the build
• should return 429 Too Many (rate limiting) if the same request is sent within a minute.
• Missing fields in the post body will be handled as unset fields
• it should save the request to the the build history collection
• actual processing of the build should be left unimplemented (implement a wrapper around the submission to a job queue or rpc call to allow that option to be configured)
• should perform basic validation of the inputs

Format and specific contents of the request / response bodies should be discussed before implementation is completed.

The login form should allow a user to sign in using a partner account (we do not want to maintain our own authentication database.

Inital partners should include:

• University of Guelph saml / oauth (this will require collaboration with CCS, @judiMc and probably @MarshallAsch
• github login

Look at passport.js and what they require to be added to the frontend to support this.

To help make sure that the code style is consistent and that 'bad' commits dont get pushed use pre-commit hooks to help enforce the style and run the tests

• eslint
• jshint (maybe)
• end-of-file-fixer
• trailing-whitespace
• some css / less / scss linter

Create the initial express.js webapp.

This should include the project skeleton and the initial project dependancies.

• express (web server)
• react (front end)
• papr (mongodb client)

This api endpoint should retrieve the users login profile and some information to be rended in the frontend:

• name
• profile picture
• email

This may be combined with how the login page returns the information about the user that just logged in

A potential plan for this project is to kick off builds of new images non interactivity through CI pipelines that should be able to be granted scoped tokens to call the apis:

The initial implementation should grant 'simple' tokens that can be used for the Create container API and the check build status API's.

A more complicated alternative to this (that would be good to have implemented is to support github and gitlab OIDC pipeline authenticate and grant access for select workflows.

Related #11

GET /api/builds

This is an admin api endpoint that can be used to fetch all the build history.

• this requires authentication
• this requires authorization as an admin user
• this must return a paged result set
• should be filterable by all, active, successful, and failed with the default being all builds.

An api should be implemented to view the fields of the previously build course containers.
This should be limited to the builds made by the currently authenticated user.

-GET /api/user/builds

• requires authentication
• should return a paged list of results page, limit
• this should be designed so that future additions to the api (ie filtering) can be added while remaining backwords compatible.

The response body should be discussed prior to implementation.

Although this image can be configured to include custom prepackaged content the content must be added manually.
To ease the usability of generating custom containers it would be beneficial to develop a webapp that can accept the inputs to create the container.

• provide git repositories containing the content

• provide a downloadable version of the image through a .zip file

• push the image to an internal registry

• push the image to a custom registry (ECR, dockerhub, github, other)

The form should accept all of the input options that are provided in the automated-builder cli.

on submit the form should prepare and send the api call to the webapp.

This should add a dockerfile to build and run the webapp.

The running of the webapp must be configurable through a config file and or envirionment variables)