Lifecycle job improvements with builtin Qovery CLI

[moisesrodriguez]

1. Currently to create a lifecycle job, the only option is to use Docker mode where you specify a Dockerfile. With this in mind if I have a script that use the Qovery CLI the only option I see available is either have a Dockerfile that installs the CLI or use

   FROM ghcr.io/qovery/qovery-cli:latest
   

   It would be great if there was a builtin Docker image to choose from that has the CLI installed, so the process is faster and no need to build it, that way we could just run a script like

   #!/bin/sh
   set -e
   qovery application domain create -n "app" --domain api.preview-$QOVERY_PULL_REQUEST_ID-domain.com
   

   and only configure the CMD arguments to run the bash script like

    ["script.sh"]
   

   

   Currently if no Dockerfile you get

   

2. Have the Qovery CLI Access Token builtin, in my tests I had to add it as an ENV variable, which first I tried using QOVERY_CLI_ACCESS_TOKEN and that was reserved and took me a while to figure out that I could use Q_CLI_ACCESS_TOKEN

   

   

3. Also have the Organization, Project and Environment ENV variables built in. If you need to overwrite them because you are pointing to another one, that is an option. But for example in a Preview Environment lifecycle job the Organization, Project and Environment for the current job is more than enough

   

[rophilogene (Romaric Philogene)]

Hi @moisesrodriguez , thanks for the feedback. Much appreciated

I put @a_carrano and @Julien_Dan in cc who will be to follow up and see what we can do.

[a_carrano (Alessandro Carrano)]

Hi @moisesrodriguez ,

I’ll try to answer point by point:

1. it makes perfectly sense, can you open an idea on our public roadmap so that we can prioritize it? (it’s not a quick change to do on our side)
2. I’ll update the documentation of the CLI to make it clear how the authentication works, indeed the info about the other token is only visible in the Github Action section of our
   doc
3. the environment name is already available, we can definitively add the other as well but the impact is not zero. if you edit the project or orga name it will have an impact on all the services in the organization (due to the injected env var). It’s something we probably avoid for now

Out of curiosity, outside the use case where you try to customize the URL of your preview environment, do you have another use case in mind where you would like to use the CLI as a workaround?

[moisesrodriguez]

Hi @a_carrano ,

Yes, other than customizing the URL in a lifecycle job with the qovery CLI:

1. Right now PR Environments leave a message in the Bitbucket Pull Request with the public URLs of my apps, but there is the case where where non-devs need certain URLs like for a frontend. We can automatize the obtaining the URL and post a comment on internal tools like MS Teams and Jira Issue.

2. Obtain the qovery generated endpoints and automatize Cloudflare DNS and Tunnel settings.

Those are two that we have in our To-do list.