GSOC Sugar Labs - How ASLO Works
This post is a break from my weekly GSOC Weekly Logs. This one is special, this one is dedicated to how ASLO works and how developers will use it.
Code and Technologies
Code is available on jatindhankhar/aslo-v3. Here is the Tech Stack
- Flask as backend framework;
- Celery for background tasks;
- Gunicorn as a WSGI server (which will be proxied by nginx in production);
- MongoDB (for internal database);
- Docker (for isolated builds);
- Github (for hosting the repos, release triggered webhooks, issue tracking);
- BootStrap Material Design for frontend.
How ASLO works
With technologies introduced above, following we’ll explain ASLO backend and frontend.
Backend
ASLO tries to leverage Github as a platform and avoid re-inventing wheel wherever possible. Code is hosted in a Github organization which is sugarlabs-test for now but eventually will be sugarlabs-activities. Whenever a developer reaches a milestone, he/she releases a new version on Github, which triggers a release webhook with event type being release.
GitHub release interface allows us to create a release for a specific tag (or create a new tag) and insert releases notes. Aside from that, it also allows us to attach binaries. Leveraging this, developers can also attach their own bundle when doing a release.
How does it works?
- Developer releases a new activity version.
- GitHub triggers a release webhook which sends a POST request with JSON payload to the ASLO app endpoint ([domain.tld]/api/hook).
- ASLO receives the HTTP request with JSON payload and verifies required headers are present like for instance X-Hub-Signature which contains the hash signature in order to verify payload is actually coming from GitHub.
- if Signature is valid, then ASLO parses the JSON payload and verifies if binaries have been attached in release. If binaries have been attached, then ASLO searches for valid .xo file. In case the .xo file is valid, then bundle won’t be built by ASLO in release process.
Hence, we can say we have two kind of releases: source releases and assets releases. A source release is a release that doesn’t contain pre-bundled .xo file while an asset release contains prebuilt .xo file, giving developer the freedom to package their own .xo.
In a source release, ASLO locally builds the .xo inside a Docker container while for an asset release just uses the pre-built .xo file attached by the developer. Let’s get a brief overview of building steps of each release.
Communication
To communicate the status back to developer we use a Github Bot, ours is named aslo-v3-bot, say hello to it here aslo-v3-bot. It communicates by commenting on the commit through which tag and release was made.
To comment on repos it needs to be member of that particular organization.
Here are two such examples, one for successful Build
and other for a failed build
It comments two times, when a build has started and other time when build is finished along with the build status. Comments are nice since, Github aslo informs the developers associated with the project. We are thinking to incorporate build status directly into the Github UI but that would require developers to use Pull Requests. To catch more errors before sending payload to ASLO, we propose to use Travis CI for each organization repo.
Database
Backend was designed in mind to support multiple release, so users can download old release of an activity.
There are two main collections activity and releases
By default new version will be shown but user can click on More Release button to discover old releases.
So each activity points to an array of ReferenceIDs which store old releases.
FrontEnd
For frontend we decided to use bootstrap-material-design
A demo can be viewed here
Frontend is in (infancy frontend branch). For now we show activity logo , developers who made that activity, a summary of the activity, categories (which we intend to use as tags) and meta data information like GTK version, license.
Each version of a activity gets an unique url which is following format bundle_id/activity_version
In case demo was inaccessible here are the screenshots
**
How developers will use ASLO
Developers will keep working on their activities and whenever they think, they are ready to publish a new activity or a version of it, they will just release it and ASLO will handle the rest 
and inform about the Build status.
Feedback and Suggestions
I would be glad to receive feedback and suggestions regarding ASLO, specially frontend.
If you want to get involved don’t be shy to Fork and sent a PR to https://github.com/jatindhankhar/aslo-v3
If you want to reach me email me either at [last_name].[first_name]@[gmail.com] or [first_name] @ [current_domain.com]
I am specially thankful to Walter,Tony,James and Chris for their inputs and Samuel (my mentor) for helping me along the way and teaching me best practices.
Comments