Skip to content

Home

Jump to bottom
Alex Laird edited this page Nov 26, 2024 · 32 revisions

This documentation should give better insight into the helium-cli, how it works, and how it can be customized and used in your own projects. To get started, have a look at the Installation and Configuration page, then move on to other pages to better understand the commands that come with this tool.

Default Multi-Project Structure

A multi-project setup means there will be a "projects" folder that may contain multiple sub-projects. In this setup, deployment configurations then also may live in their own repository, meaning a multi-project setup will have, at a minimum, three repositories (theoretically just two, but if only one subproject is going to exist, you may be better off with the single-project structure).

A multi-project directory structure is as follows:

  • root repo
    • .gitignore (should contain at least /projects)
    • ansible (for deploy-build command to work with Ansible)
      • group_vars
        • all.yml
        • <role1>.yml
        • <role2>.yml
      • hosts
        • <env1>
        • <env2>
      • <env1>.yml
      • <env2>.yml
    • projects (do not commit, as helium-cli manages this directory)
      • repo <proj1>
      • repo <proj2>

If using the helium-cli deploy-build command, the root project must contain a valid Ansible project, as illustrated by Helium's own deploy project < 1.7. If Ansible is not being used, all other helium-cli commands can still be used, just not the deploy-build command (see Helium's deploy project >= 1.7 for a Terraform example).

Default Single-Project Structure

A single-project setup means there is only one project contained within a single repository, and deployment configurations are also contained within this repo. An example of this structure can be found in the django-bootstrap-authentication-template-project project.

A single-project directory structure is as follows:

  • repo
    • .gitignore
    • ansible (for deploy-build command to work with Ansible)
      • group_vars
        • all.yml
        • <role1>.yml
        • <role2>.yml
      • hosts
        • <env1>
        • <env2>
      • <env1>.yml
      • <env2>.yml

A few things need to be configured for the helium-cli to work in this single-project setup. First, projectsRelativeDir (HELIUMCLI_PROJECTS_RELATIVE_DIR) needs to be set to ".", and versionInfo.project (HELIUMCLI_VERSION_INFO_PROJECT) needs to be ".".

Defaults

When helium-cli is first run, a configuration file for the current project (directory) will be created (you'll probably want to commit this file) using default values. These defaults, including the expected project structures defined above, can be overridden by modifying environment variables, as defined here, prior to initializing a helium-cli project.

When the command helium-cli update-projects is first run, projects will be populated by cloning all repos of HELIUMCLI_GIT_PROJECT matching a project name in the HELIUMCLI_PROJECTS list. So, for example, HELIUMCLI_GIT_PROJECT defaults to https://github.com/HeliumEdu and HELIUMCLI_PROJECTS defaults to ["platform", "frontend"].

Template Project

The helium-cli template project is initialized from the repo found here. Using the helium-cli init command, a preconfigured Django template project, as well as a .heliumcli.yml config file, will be generate for you based on the parameters you pass to the command.

Clone this wiki locally