You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While working on project creation progress, I had this brainwave that at some point it'd be a good idea to have dedicated deployments handling bits. Essentially when you POST to /projects/42/applications it would come with a deployment_uuid that would be used for progress reports and the like.
Perks
Ability to check if a deployment is already happening before starting a new one
If a deploy fails at any point, its status can be updated to reflect that
If logs are saved to a deployment, they can be retrieved should the page be refreshed
In future, things like branch and/or commit SHA could be saved with the deployment, adding the possibility of re-deploying a previous "build" if a new commit breaks things etc.. Better yet, if the app 'source' (ie github/bitbucket/whomever) were stored in its own table, we could easily reference it from both the project and any deployments.
Example endpoints
POST /projects/69/deploy -- to deploy a project
{ uuid: 'aef1c239d', complete: false }
GET /deployments/aef1c239d -- to view status of a deployment
{ uuid: 'aef1c239d', project_id: 69, complete: false }
The text was updated successfully, but these errors were encountered:
Rather than a fully-fledged deployments system, it may be enough to simply create projects as a draft as soon as the "New Project" page is entered.
Would add a bit of complexity in terms of checking for existing drafts (or having redundant drafts build up), but it would mean we have a Project ID before the progress modal is initialised, thus the monitor can be setup in the background.
One downside though: we still wouldn't immediately know wether to display steps for app or redirect creation.
While working on project creation progress, I had this brainwave that at some point it'd be a good idea to have dedicated deployments handling bits. Essentially when you
POST
to/projects/42/applications
it would come with adeployment_uuid
that would be used for progress reports and the like.Perks
In future, things like branch and/or commit SHA could be saved with the deployment, adding the possibility of re-deploying a previous "build" if a new commit breaks things etc.. Better yet, if the app 'source' (ie github/bitbucket/whomever) were stored in its own table, we could easily reference it from both the project and any deployments.
Example endpoints
The text was updated successfully, but these errors were encountered: