kgalli / cliw Goto Github PK

The main configuration is basically an enriched docker-compose format. Currently it is pretty annoying to go to docker hub to see a docker-compose config sample which has to be ported to JSON before it can be used.

Additionally, the industry seems to have settled to YAML for this kind of configuration.

Next to Postgres CLIW should also support to manage a MySQL database.

It is often necessary to run a different version of a particular docker image in development to test a Pull Request or similar. To deal with this you have to update the docker-compose / cliw config every time you need this change. Furthermore, it is very easy to get confused which version is running write now. Not to mention that when you need to run several different versions in a kind of testing environment it is unnecessarily complicated to automate the change of the configuration. I recommend adding a feature like cliw service:origin to be able to overwrite the version.

"buildOrigin": {
  "registry": {
    "image": "kgalli/api-service:<This PART IS CHANGABLE VIA CONFIG>"
  }
}

Currently the service:origin:set does not support environments. Hence if a service is set to SOURCE it will be build from source for all environments.

Expected:

• the command supports the -e environment option and persists accordingly
• service started in specific environment rely on what is configured for that environment

The tests work fine after the first run. However, consecutive executions of npm test will raise this error:

  2) lists services run-types

  exec
(node:19506) [EEXIST] Error Plugin: orchestrator: EEXIST: file already exists, mkdir '/Users/jlijo/.config/orchestrator'
module: @oclif/[email protected]
task: toCached
plugin: orchestrator
root: /Users/jlijo/Documents/opensource/orchestrator
See more details with DEBUG=*

Running the tests for first time are creating a folder in this path /Users/jlijo/.config/orchestrator.

Removing the orchestrator folder after each test as a workaround.

As --dry-run (kebab-case) is more widely used for CLIs then camel-case.

Example for Up command.

import {flags} from '@oclif/command'

import {dryRunFlag, environmentFlag, servicesFlag} from '../flags'
import DockerComposeCommand from '../wrapper/docker-compose'

export default class Up extends DockerComposeCommand {
  static description = 'build, (re)create, start, and attach to containers'

  static flags = {
    services: servicesFlag,
    environment: environmentFlag,
    'dry-run': dryRunFlag,
    help: flags.help({char: 'h'}),
  }

  async run() {
    const {flags} = this.parse(Up)
    const services = flags.services
    const environment = flags.environment
    const dryRun = flags['dry-run']

    try {
      this
        .dockerCompose(dryRun)
        .up({}, services, environment)
    } catch (e) {
      this.error(`${e.message}\nSee more help with --help`, e)
    }
  }
}

Currently docker network has to be created manually before a service:[command] e.g. service:start can be executed.

The error:

ERROR: Network cliw_development declared as external, but could not be found. Please create the network manually using `docker network create cliw_development`

Idea is to provide a command which will create necessary docker networks (one for each environment) and optionally also clones defined internal service repositories of those are missing.

Let's assume I have a main config that does not have the service with the name "non-existing-service" defined.

When running:

cliw service:origin:set non-existing-service source

Expected
I expect it to fail with the error message that this service is not defined.

Actual
Instead, it updates the service-build-origins.json with this service.

Determine if a command like cliw db:create is run in a tty. If not do not add the -t flag to docker-compose command. Same for -i flag. Only add it when needed.

# https://nodejs.org/api/tty.html
# The preferred method of determining whether Node.js is being run within 
# a TTY context is to check that the value of the process.stdout.isTTY property is true:

$ node -p -e "Boolean(process.stdout.isTTY)"
true
$ node -p -e "Boolean(process.stdout.isTTY)" | cat
false

By setting the runType either to src or image commands like start or run will build the image first and then execute.

db:restore fails when using a dump file in plain format.

It's currently failing with:

pg_restore: error: did not find magic string in file header

More info can be found here:
https://dba.stackexchange.com/a/111910/205867

Currently using the init command the default project is created. Under the hood cliw already supports multiple projects and uses the default project to determine what to do (which projects config to pick) when a command is called.

The missing part is to actually provide a way through the interface that the user can set multiple projects and the default project.

As of now the db sub command utilizes docker postgres image and uses "normal" connection setting without the option to specify something like :

psql "service=myservice sslmode=require"
# or
psql [options] -d "dbname=postgres sslmode=require" [other options]
# or 
psql [options] "dbname=postgres sslmode=require"

conninfo string

It would be useful to have a command like:

cliw service:list

to know all available services that can be started/stopped within the active project.

I know about the cliw service:status, but I think it will not list services that never started.

Running cliw service:start the first time will end up in and error similar to this:

ERROR: Network demo-network_development declared as external, but could not be found.
Please create the network manually using `docker network create demo-network_development`
and try again.

Even though the error message is really descriptive I think we are better off adding a subcommand that sets up all necessary docker networks.

To set the runtype for a particular service the config:set command is used. Due to the fact that runtype is specific to the service command which wraps docker-compose it should not be supported by the hight level config command.

The idea is to move the command under service:config or more to be more specific under service:runtype.

As a developer who might work on different projects at the same time I could be interested in being able to run commands on specific projects, so that I don't have to switch cliw contexts when I want to do so.

i.e:
cliw start -p zalenium -s api