Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for continuous deployment (CD) policies in project stages #117

Open
IvanVlasic opened this issue Mar 4, 2022 · 3 comments
Open
Assignees

Comments

@IvanVlasic
Copy link
Contributor

We're adding an option for integration stage which will be connected to specific repository branch and deploy all changes automatically on each push.

This feature should generate github action workflow and place it in appropriate folder inside the repository (.github/workflows) and generate token which the workflow can use for authentication to the node during the deploy.

@IvanVlasic IvanVlasic self-assigned this Mar 4, 2022
@IvanVlasic
Copy link
Contributor Author

IvanVlasic commented Mar 4, 2022

Current iteration of this feature looks like this:

User can add existing stage as integration stage through aws integration add <stage>.

As mentioned above, this command will generate appropriate workflow file and token used for authentication.

By default, the workflow file will be created in the local repository and user will be presented with instructions on where to add secret in the repository and under which name.

Optionally, user can use --repo option and specify repository to which they want integration to be added to. With this option Mantil will attempt to automatically push workflow file and add secret to the github repository eliminating any manual work from the user's side.

If the repository user is using is not personal repository but is instead located inside organisation, user can use option --github-org. With this option Mantil will try to use repository with specified name inside that github organisation.

If --repo option is present user needs to also specify a github token which will be used for authentication while interacting with the repository. This can be done either by providing --github-token option or through GITHUB_TOKEN environment variable.

@patko
Copy link
Member

patko commented Mar 4, 2022

I'd do it differently.

Instead of introducing a new subcommand integration, I would extend the stage subcommand with a --cd-policy option (cd as in continuous delivery). Default, the option is manual which means that the project is deployed only by a human intervention.

Then, the --cd-repo option always follows the --cd-policy. The cd-repo provides a URL for the GitHub repository. I have a knowledge gap here. I understand GH Actions need a workflow file. Does it have to be in the same repository with the project? Does it make sense to use the current project's repository as a default option?

If Mantil uses GitHub URL, then organization name is superfluous.

So, the whole command would typically look like:

mantil stage new integration --cd-policy on-commit --cd-repo https://github.com/mantil-io/mantil --cd-token *********

@patko patko changed the title Add option for integration stage Add support for continuous deployment (CD) policies in project stages Mar 7, 2022
@IvanVlasic
Copy link
Contributor Author

I've changed this to work as a part of stage new subcommand and added cd-policy option which is by default set to manual.

Command looks like this:
mantil stage new integration --cd-policy on-commit --cd-token *********

Repository is not needed as Mantil can check remotes locally. It looks for for origin remote and parses user and name of the repository from the remote's URL.

Right now setting on-commit as cd-policy will always try to push workflow file and secret to the github repository but we can also change that behaviour and allow user to just create workflow file locally and output secret in the terminal so they can manually add them to the repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants