search

slackapi / deno-slack-sdk

SDK for building Run on Slack apps using Deno
https://api.slack.com/automation
MIT License
158 stars 27 forks source link

[QUERY] How to add env variables from CI #351

Closed djmgit closed 1 week ago

djmgit commented 1 month ago

Question

How to add env variables from CI? I am trying the following:

slack env add -w ${SLACK_ORG_ID} --token ${SLACK_SERVICE_TOKEN} key val

However its throwing the following error:

A valid installation of this app is required to take this action (installation_required)

Suggestion

   Install the app with `slack install`

However I am running this command after deploying the app using:

slack deploy -s -w ${SLACK_ORG_ID} --token ${SLACK_SERVICE_TOKEN}

So I believe the app is already installed since I am able to use it as well.

I am using bitbucket pipelines.

Environment

cat import_map.json | grep deno-slack "deno-slack-sdk/": "https://deno.land/x/deno_slack_sdk@2.14.0/", "deno-slack-api/": "https://deno.land/x/deno_slack_api@2.7.0/",

deno --version deno 1.44.4 (release, aarch64-apple-darwin) v8 12.6.228.9 typescript 5.4.5

sw_vers && uname -v ProductName: macOS ProductVersion: 13.6.7 BuildVersion: 22G720 Darwin Kernel Version 22.6.0: Mon Apr 22 20:51:27 PDT 2024; root:xnu-8796.141.3.705.2~1/RELEASE_ARM64_T6020

Requirements

filmaj commented 1 month ago

Hello @djmgit , I am trying to reproduce this and failing... can you tell me how you retrieved the service token being provided to the deploy and env commands?

filmaj commented 1 month ago

I am using bitbucket pipelines.

Are the two commands (deploy then env) being run in the same pipeline session? If not, then the state that the CLI relies on and persists to project .slack/apps.json files would not be present, so the CLI would not "know" that the app has already been deployed.

djmgit commented 1 month ago

@filmaj I got the token by running slack auth token and following the steps from my terminal. I am using the same in the pipelines as well.

Following is the single pipeline step

- step: &deploy-slack-workflows-stage
      name: Deploy slack workflow to stage
      script:
        - curl -fsSL https://downloads.slack-edge.com/slack-cli/install.sh | bash
        - slack --version
        - cd slack_deno/workflows
        - slack deploy -s -w ${SLACK_ORG_ID} --token ${SLACK_SERVICE_TOKEN}
        - slack env add -w ${SLACK_ORG_ID} --token ${SLACK_SERVICE_TOKEN} key val

I also tried the following:

- slack deploy -s -w ${SLACK_ORG_ID} --token ${SLACK_SERVICE_TOKEN} && slack env add -w {SLACK_ORG_ID} --token ${SLACK_SERVICE_TOKEN} envtype deployed

Interestingly now I got this error:

The provided token is not valid (invalid_token)

   The workspace flag is not associated with the provided token

Check /root/.slack/logs/slack-debug-20240813.log for error logs

This error was thrown after the deploy part worked fine. The same command with && when run from my terminal works fine.

filmaj commented 1 month ago

@djmgit maybe because the command you posted in your last comment is missing a $ in front of the environment variable in env add -w {SLACK_ORG_ID} ?

filmaj commented 1 month ago

A few other notes when automating this command:

I was also not able to reproduce this locally in my terminal, which leads me to believe there may be something else going on within the context of the deployment pipeline.

Can you add an ls -al .slack in between the deploy and env command, to see if the .slack directory exists and has an apps.json inside it? Possibly you may want to also cat out the contents of .slack/apps.json, to ensure the CLI persisted application deployment information to that file. Without this file in place, the CLI would not know which app to set the environment variable on, which would cause the installation_required error code.

One more suggestion to help figure out what is going on: use the --verbose flag w/ the slack invocations to get more information as to what the CLI is doing and what is happening.

djmgit commented 1 month ago

@filmaj I changed my step definition to the following:

 - step: &deploy-slack-workflows-stage
      name: Deploy slack workflow to stage
      script:
        - curl -fsSL https://downloads.slack-edge.com/slack-cli/install.sh | bash
        - slack --version
        - cd slack_deno/hot_workflows
        - ls -al .slack && cat .slack/apps.json
        - slack deploy -s -w 123456789 --token ${SLACK_SERVICE_TOKEN}
        - ls -al .slack && cat .slack/apps.json && slack env add -v -w 123456789 --token ${SLACK_SERVICE_TOKEN} key val

I hardcoded the org id instead of using repo variables and also printing the contents of apps.json before and after the deploy command. The deploy command worked as usual. The env command failed with the install error. The contents of apps.json is same before and after the deploy command.

{
  "apps": {
    "123456789": {
      "app_id": "aaaaaaaaaaa",
      "enterprise_id": "123456789",
      "team_domain": "atlassian",
      "team_id": "123456789"
    }
  },

In the verbose logs I can see it made two calls to 

POST https://slack.com/api/apps.status HTTP/1.1

The first one had request body:

{"app_ids":["aaaaaaaaaaa"],"team_id":"123456789"}

and the response was the app details with enterprise id, team domain, team id etc.

The second call was made with request body:

{"app_ids":["aaaaaaaaaaa"]}

(no team_id)

and the response was

{"ok":false,"error":"not_authed"}
filmaj commented 1 month ago

Interesting. What version of the slack CLI are you using? slack --version should tell you.

Another bit of info that could help: how many CLI session tokens are present in the ~/.slack/credentials.json file in this situation? Since this is happening in a deployment pipeline context / use of flag-provided tokens, my guess would be none / that file does not exist, but I would like to confirm.

Is there any chance you could send me a copy of the verbose output of the slack env command? I understand it contains sensitive information, so it is completely up to you and I understand that this may not be simple for you. If you are OK doing it, you can send the log to me via our community.slack.com Slack workspace via DM; I am @filmaj on there as well.

If you would rather not share that information with me, I will have to direct you to submit an issue to our customer support team by emailing feedback@slack.com. You can link them to this issue, and provide them the verbose logs.

djmgit commented 1 month ago

@filmaj 

slack --version

Using slack v2.29.1
cat /root/.slack/credentials.json | grep '"token"' | wc -l
0
djmgit commented 1 month ago

@filmaj also how do I login/signup to community.slack.com ?

filmaj commented 1 month ago

@djmgit To join the workspace, create an account on either slackcommunity.com or forums.slackcommunity.com. In the welcome email that follows, you will see a link to join the workspace directly.

djmgit commented 3 weeks ago

@filmaj thanks, checking

filmaj commented 3 weeks ago

Some information that came out of what @djmgit shared with me: the app is installed to an enterprise grid, but has a workspace grant to a specific sub-grid workspace - this may have something to do with the issue. Will investigate more later today.

filmaj commented 3 weeks ago

I was able to reproduce this! It took a little bit of work, but here are the repro steps:

  1. Make sure you have access to an enterprise grid organization, with at least one sub-workspace in it.
  2. Create a new app, e.g. the hello world deno app. slack create -t slack-samples/deno-hello-world ./dhw-test
  3. Make sure you are logged into the enterprise grid workspace via slack login.
  4. Create an auth token (for use in e.g. CI pipelines): slack auth token. Save it as e.g. the SLACK_CLI_TOKEN env var.
  5. Deploy the app 'manually' using the CLI, but crucially, select a sub-workspace to "grant" the app to. slack deploy. In the example I paste here, my enterprise grid is called devrel-slack but my sub-workspace is called Tools: 
    
? Choose a deployed environment Install to a new team
? Install to a new team devrel-slack E03JJKSMCER

🔔 If you leave this team, you can no longer manage the installed apps Installed apps will belong to the team if you leave the workspace

💡 Your app will be installed to the "devrel-slack" organization If you'd like, you can restrict access to only users in a particular workspace

? Choose a workspace to grant access: Tools T03JJMHCVMK


6. Now, delete your `~/.slack/credentials.json` file. We are now simulating executing in a CI environment, where saved CLI credentials are not stored (thus why we use the CLI token via command line flags).
7. Deploying in this context works fine: `slack deploy -s -w E03JJKSMCER --token $SLACK_CLI_TOKEN`
8. However, adding an environment variable does not: `slak env add -s -w E03JJKSMCER --token $SLACK_CLI_TOKEN envtype deployed`

Workaround: provide the `--app` flag and pass your app ID. In my situation, the following command worked fine:

➜ slack env add -s -w E03JJKSMCER --token $SLACK_CLI_TOKEN --app A07JMJML69E envtype deployed APP A07JMJML69E ✨ successfully added envtype to app environment variables



Going to see if this is a legit bug / if the `--app` flag is needed.
djmgit commented 3 weeks ago

@filmaj this worked, thanks a lot 👍

filmaj commented 3 weeks ago

FYI, our team looked into this and it turns out it's a bug in the Slack CLI. We have a fix ready, and we expect to release it in the next two weeks. In the mean time, hopefully the --app flag is not a terrible experience.

Stepping back, in general, I would highly recommend providing the --app flag always in CI environments. I say this because some CLI commands may apply to locally-running apps (slack run) as well as deployed apps (slack deploy). The --app flag disambiguates this. Without it, you leave it up to the CLI to determine which app to target based on the local state of the .slack/apps.json and ~/.slack/credentials.json file. In this case, obviously, that code had a bug. Software amirite? 😅 Just my 2 cents!

In any case I'll leave this issue open until we ship a new CLI version that fixes this.

filmaj commented 1 week ago

This should be fixed in the CLI 2.29.2, which was released yesterday.