There is no way to automate the deployment via CI / CD because vtex login does not support token auth

[rod-dot-codes]

As a Software Engineer, I want to automate deployments to workspaces using Github Actions or Jenkins, but there is no supported login method besides the browser login route which does not work for automated processes.

This dramatically hinders our ability to do effective git flow - since manual steps have to be followed for each release.

Expected Behavior

I want to be able to login with a Private Access Token, even if we have to rotate this weekly and run a vtex setup and vtex link headless for a workspace specified.

Current Behavior

You can only login via the popup based browser flow which limits any modern CI / CD process that will allow us clean, consistent, repeatable deployments.

---

If this is on the roadmap, or there is a workaround - I would love to know.

[simmbiote]

+1

[cantoniazzi]

@rod-dot-codes @simmbiote You can automate the log-in by Vtex API to generate the session token using your appkey and apptoken ( https://vtexid.vtex.com.br/api/vtexid/apptoken/login?an=your_account_name_here)

E.g

curl --location --request POST 'https://vtexid.vtex.com.br/api/vtexid/apptoken/login?an=your_account_name_here' \
--header 'Content-Type: application/json' \
--data-raw '{
    "appkey": "YOUR_APP_KEY",
    "apptoken": "YOUR_APP_TOKEN"
  }'

Then take a look at your local environment in the ~/.vtex/session folder with the files session.json, tokens.json, and workspace.json.

With the generated token you can create the JSON files with it and the other fields use environment variables from your repositories, such as the account name and the workspace name.

Then you share this artifact (~/.vtex/session folders and the populated .json files) between your deploy steps (publish, deploy, and promote).

I did this workaround and it works like a charm. 💅🏾

[rod-dot-codes]

Awesome - thanks @cantoniazzi - I am going to try it out tonight! This is going to save us a lot of effort trying to keep our QA environments in sync.

Will report back..

[cantoniazzi]

We implemented this in our store CI pipeline.
In case of any problems, you can ping me here @rod-dot-codes .

[achirus-code]

+1 @cantoniazzi can you share some more infos? Did you build your own plugin to create these files by your own?

Thanks a lot :)

[achirus-code]

I wrote a mini bash. I hope it will help you guys.

#!/bin/bash

vtex_path="$HOME/.vtex/session/";

session_file="session.json"
workspace_file="workspace.json"
token_file="tokens.json"

vtex_workspace="master"
vtex_account="youraccount"
vtex_appkey="yourkey"
vtex_apptoken="yourtoken"



echo "fetch vtex token"

token_curl=$(curl -s --location --request POST "https://vtexid.vtex.com.br/api/vtexid/apptoken/login?an=$vtex_account" \
--header 'Content-Type: application/json' \
--data-raw '{
"appkey": "'$vtex_appkey'",
"apptoken": "'$vtex_apptoken'"
}') || exit

echo "... got it"

echo "create session.json"

resonse=$(jq ".account = \"$vtex_account\"" <<<"$token_curl")
jq ".login = \"$vtex_appkey\"" <<<"$resonse" > "$vtex_path$session_file"

token=$(printf '%s\n' "$resonse" | jq -r .token)

echo "... successful created session.json"

echo "create workspace.json"

echo '{
         "currentWorkspace": "'$vtex_workspace'",
         "lastWorkspace": null
 }' > "$vtex_path$workspace_file"

echo "... successful created workspace.json"
echo "create tokens.json"

echo "current Token is $token"

echo '{
          "'$vtex_account'": "'$token'"
  }' > "$vtex_path$token_file"

echo "... successful created tokens.json"

[rod-dot-codes]

I did something similar @TillmannD - but in Python, cause well, like my Bash ain't that strong. 🤖

I'm currently building some custom Github Actions for my team to automate deployments, I will share once done, and they are working without issues. I have to modify the Toolbelt due to the custom yes / no prompts for some of the commands.

import requests
import os
import json
import pathlib

VTEX_ENV = os.environ.get('VTEX_ENVIRONMENT').lower()
VTEX_APP_KEY = os.environ.get('VTEX_APP_KEY')
VTEX_APP_TOKEN = os.environ.get("VTEX_APP_TOKEN")


response = requests.post(f"https://vtexid.vtex.com.br/api/vtexid/apptoken/login?an={VTEX_ENV}", json={'appkey': VTEX_APP_KEY, 'apptoken': VTEX_APP_TOKEN})
response.raise_for_status()

ROOT_DIRECTORY = pathlib.Path.home().joinpath(".vtex").joinpath("session")
os.makedirs(ROOT_DIRECTORY.as_posix())
print(ROOT_DIRECTORY.as_posix())


with open(ROOT_DIRECTORY.joinpath("session.json").as_posix(), "w+") as f:
    main_session = response.json() | {"account": VTEX_ENV, "login": VTEX_APP_KEY}
    json.dump(main_session, f, indent=4, sort_keys=True)


with open(ROOT_DIRECTORY.joinpath("token.json").as_posix(), "w+") as f:
    json.dump(response.json(), f, indent=4, sort_keys=True)


with open(ROOT_DIRECTORY.joinpath("tokens.json").as_posix(), "w+") as f:
    tokens = {VTEX_ENV: response.json()["token"]}
    json.dump(tokens, f, indent=4, sort_keys=True)


with open(ROOT_DIRECTORY.joinpath("workspace.json").as_posix(), "w+") as f:
    json.dump({"currentWorkspace": "master", "lastWorkspace": None}, f, indent=4, sort_keys=True)

print ("Login succeeded!")

[achirus-code]

@rod-dot-codes
nice ! <3

Do you also needed to set the deployCli -> enabled to false in the cy-runner.yaml to get it work?

[cantoniazzi]

guys, in GitLab I put the JSON's generated by the login as an artifact, that way I can share them between stages.

[cantoniazzi]

some like that (ps: your runner needs jq installed):

login:
  stage: login
  script:
   - |
      TOKEN=$(curl -s POST 'https://vtexid.vtex.com.br/api/vtexid/apptoken/login?an='${ACCOUNT_NAME}'' \
      --header 'Content-Type: application/json' \
      --data-raw '{"appkey": "'${APP_KEY}'", "apptoken": "'${APP_TOKEN}'"}' | jq --raw-output '.token')
      mkdir -p .vtex/session
      jq -n --arg account "${ACCOUNT_NAME}" --arg login "${ACCOUNT_EMAIL}" --arg token "${TOKEN}" '$ARGS.named' > .vtex/session/session.json
      jq -n --arg "${ACCOUNT_NAME}" "${TOKEN}" '$ARGS.named' > .vtex/session/tokens.json
      jq -n --arg currentWorkspace "${WORKSPACE}" '$ARGS.named' > .vtex/session/workspace.json
artifacts:
    paths:
      - .vtex

it's interesting let the variables (APP_KEY, APP_TOKEN, etc) as environment variables, so you can store it in your repository ci/cd settings 👯.

with GitHub, I think you can upload/download the artifacts and reuse the token between vtex IO deploy flow (publish, deploy).

https://github.com/actions/upload-artifact
https://github.com/actions/download-artifact

[thyarles]

Hi @rod-dot-codes, @cantoniazzi, and @achirus-code,

Today I reach this thread because we need to improve the login time on cy-runner and this way to login on vtex toolbelt will incredible reduce the time to do a login.

@achirus-code, even using the bash code you need to keep deployCli enabled if you are using GitHub because this is the only way to get toe tool installed on it. Maybe you can disable the secrets as you'll do a login using the script.

I'll start working to change the cy-runner to take advantage of this new way to login, it'll be faster and reliable. Today we need to send verification code to Twilio and do the login process using Cypress like a final user do.

@rod-dot-codes, I'm really interested on this action. Do you need any help? It'll be awesome if this action:

1. Deploy the toolbelt with the patched version (ithe branch must be a parameter as I have one and you have other customized to avoid prompts)
2. Cache the packages to make the next deploy with the same setup faster
3. Do the login logic using the bash or the python script
4. Throw an error if anything goes wrong, so the pipeline will stop

What do you think?

[thyarles]

some like that (ps: your runner needs jq installed):

login:
  stage: login
  script:
   - |
      TOKEN=$(curl -s POST 'https://vtexid.vtex.com.br/api/vtexid/apptoken/login?an='${ACCOUNT_NAME}'' \
      --header 'Content-Type: application/json' \
      --data-raw '{"appkey": "'${APP_KEY}'", "apptoken": "'${APP_TOKEN}'"}' | jq --raw-output '.token')
      mkdir -p .vtex/session
      jq -n --arg account "${ACCOUNT_NAME}" --arg login "${ACCOUNT_EMAIL}" --arg token "${TOKEN}" '$ARGS.named' > .vtex/session/session.json
      jq -n --arg "${ACCOUNT_NAME}" "${TOKEN}" '$ARGS.named' > .vtex/session/tokens.json
      jq -n --arg currentWorkspace "${WORKSPACE}" '$ARGS.named' > .vtex/session/workspace.json
artifacts:
    paths:
      - .vtex

it's interesting let the variables (APP_KEY, APP_TOKEN, etc) as environment variables, so you can store it in your repository ci/cd settings dancers.

with GitHub, I think you can upload/download the artifacts and reuse the token between vtex IO deploy flow (publish, deploy).

https://github.com/actions/upload-artifact https://github.com/actions/download-artifact

Just a warning here... all artifacts from public repositories are public on GitHub. So, take care 👀.

[cantoniazzi]

some like that (ps: your runner needs jq installed):

login:
  stage: login
  script:
   - |
      TOKEN=$(curl -s POST 'https://vtexid.vtex.com.br/api/vtexid/apptoken/login?an='${ACCOUNT_NAME}'' \
      --header 'Content-Type: application/json' \
      --data-raw '{"appkey": "'${APP_KEY}'", "apptoken": "'${APP_TOKEN}'"}' | jq --raw-output '.token')
      mkdir -p .vtex/session
      jq -n --arg account "${ACCOUNT_NAME}" --arg login "${ACCOUNT_EMAIL}" --arg token "${TOKEN}" '$ARGS.named' > .vtex/session/session.json
      jq -n --arg "${ACCOUNT_NAME}" "${TOKEN}" '$ARGS.named' > .vtex/session/tokens.json
      jq -n --arg currentWorkspace "${WORKSPACE}" '$ARGS.named' > .vtex/session/workspace.json
artifacts:
    paths:
      - .vtex

it's interesting let the variables (APP_KEY, APP_TOKEN, etc) as environment variables, so you can store it in your repository ci/cd settings dancers.
with GitHub, I think you can upload/download the artifacts and reuse the token between vtex IO deploy flow (publish, deploy).
https://github.com/actions/upload-artifact https://github.com/actions/download-artifact

Just a warning here... all artifacts from public repositories are public on GitHub. So, take care 👀.

Good point @thyarles. My repo's private.

[thyarles]

Hi there,

I was so excited about this topic and the proposed solutions that I couldn't wait! With insights from this thread I was able to build the VTEX Toolbelt Action to deploy and login whatever you need using GitHub actions. This was an issue we've had on the US Team for Cypress tests since last year and we decided to address it this week. You guys give me a wonderful shortcut, thanks!

BTW, the first version was published and it fully suits our needs. If you need something more, please, let me know.

[rod-dot-codes]

@thyarles I am super stoked to test this out! A big improvement - and this is the type of work VTEX should do to make our lives easier to roll this out! Great work!

[thyarles]

@thyarles I am super stoked to test this out! A big improvement - and this is the type of work VTEX should do to make our lives easier to roll this out! Great work!

Hi @rod-dot-codes, thanks, I totally agree! Your code with the other ones here make it way easier... it needs a lot of fix to work for every pipeline, though. The improvement I want to make now is: instead of download a repository and build the customized VTEX Toolbelt, I want to publish this "special" version on NPM... something we can install using yarn global add vtex@3.0.0-beta-ci.

You mention that you made some customization on the VTEX Toolbelt to avoid the YES/NO questions. Is that version published on NPM? Can you share it with us?

[rod-dot-codes]

I will publish it this week, just been busy with first-month implementation issues on a new VTEX site - we are getting there but I am keen to share my versions to see if it makes it easier for us to grow this in the long term.

[thyarles]

I will publish it this week, just been busy with first-month implementation issues on a new VTEX site - we are getting there but I am keen to share my versions to see if it makes it easier for us to grow this in the long term.

Awesome, looking for it. If you need any help on that, count on me.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.