Deploy button for apps

[beydogan]

Hi! I was building https://github.com/beydogan/dokku-man, very similiar app to intercity-next but I just saw your project(reddit ad) and decided to discontinue it and support intercity-next development.

One of the key features I needed was deploy button and deploy hook(triggered by CIs) for apps. I have this feature on dokku-man but its highly WIP. I would like to add this feature to intercity-next if its on your roadmap and we can discuss details.

[jvanbaarsen]

@beydogan Awesome to hear that you're willing to help us out! Can you explain in a bit more detail how you're planning to build this feature? I like the idea of this feature :-)

Let's see if we can get in a shared direction before you start building it :-)

[michiels]

@beydogan I think you're mentioning two options in your message: 1) a deploy button 2) deploy hook triggered by CIs.

Option 2 is already quite possible if you let your CI git-push to the Dokku remote that Intercity sets up. Altho of course can write documentation for that to make it clear.

A deploy button sounds interesting! I concur with @jvanbaarsen to hear your thoughts!

[beydogan]

Here is a short video from dokku-man deployment button: https://www.youtube.com/watch?v=QdUy8-Ttym0. User selects the branch to deploy and clicks deploy button, then it prints out the logs using ActionCable.

A public/private key pair should be added to each app. Public key will be added to git repo as deployment key.

Steps for deployment;

• Clone git repo and checkout to the branch to deploy
• Add dokku server as a remote
• Push to dokku
• Delete local files

Related code from dokku-man: https://github.com/beydogan/dokku-man/blob/feature/deploy_button/app/models/concerns/app_commands.rb#L64

[jvanbaarsen]

@beydogan Wow, the behaviour looks nice! I also checked the way you implemented it in your current project. I'm not sure if that is the way to go in terms of maintainability. Let me think about a way this could be implemented and maintained in a pain free manner. I'll come back to you on this later today!

[beydogan]

@jvanbaarsen I agree that its not a good implementation it was the POC code and need to be refactored :+1: I would like to hear your thoughts.

[jvanbaarsen]

@beydogan Ok I have been thinking about this for a bit. There are a few concerns that I have which we need to figure out:

1. We can't check out code on the IC server itself. So we need to figure out a way to do this inside a docker container of some sort
2. The branch list should not be fetched on every request. This will cause the page to render very slow
3. There should be a clean/easy way to authorise your git repo with Intercity. We can decide to use OAuth for this, and from the get go support Gitlab and Github. We can also decide that the user has to add a SSH key to Gitlab or Github repo so Intercity can access it.
4. The logging/reporting system should be something that can work across multiple command, not just this one. (For example, it would be nice to show the install output as well). See below for how I'm currently thinking about this.

Logging system For the logging I'm thinking about the following DB tables:

executed_command
--------------------
- command:string/text
- exit_code
- final_log:text

executed_command_log_line
----------------------
- executed_command:references
- log:text

This way we can use the logging system also for the command that run in the background (For example adding env-vars etc.), and have the user see a history of commands and their output.

Once a command is finished, we can concat all the executed_command_log_lines into the ExecutedCommand#full_log field.

Still not 100% sure how this feature would look. Do you have solutions for the above concerns?

[beydogan]

@jvanbaarsen

1. I agree with this, its not a good practice to checkout the code on server, running a container might be a better option.
2. In my implementation, its not fetched on every request, user needs to sync branches first and it stores branches of the app in db.
3. I think adding SSH key to GitHub, GitLab, Bitbucket etc. is easy for user and easiest for development too.
4. Logging system and db models you proposed looks, one thing is maybe we can store the user who executed the command(if multiple users can/will access to an app)