Hi, Atmos Pro: 403 . What can I be doing wrong? I added a new repo to Atmos Pro (and removed the first one just in case), so only one repo installed. Running

atmos describe affected ... --upload

does retrieve and print the stack information, including the workspace_id, but fails uploading:

ERRO  Pro API Error operation=UploadAffectedStacks request="" status=403 success=false trace_id=b11636f3f0e1e158947bd5abfe7a4d35 error_message="" context=map[]
# Error
**Error:** failed to upload stacks API response error: API request failed with
status 403 (trace_id: b11636f3f0e1e158947bd5abfe7a4d35)

It's most likely due to permissions https://atmos-pro.com/docs/learn/permissions

Oh, yes. The permissions were of course per repo. Thanks.

We will improve the error message!

My next error is

<https://github.com/forterro-prd/pen-demoapp-deployment/pull/1/checks?check_run_id=68881772619|Atmos Pro> Failing after 39s — Failed to dispatch Atmos Pro workflows

. Here is my imported atmos-pro mixin config:

config: &plan-wf-config
  atmos-terraform-plan.yaml:
    inputs:
      component: "{{ .atmos_component }}"
      stack: "{{ .atmos_stack }}"

settings:
  pro:
    enabled: true
    workspace_id: "xxxxxxxxxxxxxxxxxxxxxxx" # This is not a secret. Can be defined with ATMOS_PRO_WORKSPACE_ID
    # github_oidc:
    #   request_url: !env ACTIONS_ID_TOKEN_REQUEST_URL
    #   request_token: !env ACTIONS_ID_TOKEN_REQUEST_TOKEN

    drift_detection:
      enabled: false

    pull_request:
      opened:
        workflows: *plan-wf-config
      synchronize:
        workflows: *plan-wf-config
      reopened:
        workflows: *plan-wf-config

And my .github/workflows/atmos-terraform-plan.yaml starts with

name: 👽 Atmos Pro Terraform Plan
run-name: plan ${{ inputs.component }}/${{ inputs.stack }}/${{ inputs.atmos_pro_run_id}}

on:
  workflow_dispatch:
    inputs:
      atmos_pro_run_id:
        description: "Atmos Pro Run ID"
        type: string
      sha:
        description: "Commit SHA"
        type: string
      component:
        description: "Component"
        required: true
        type: string
      stack:
        description: "Stack"
        required: true
        type: string
      upload:
        description: "Upload plan status to Atmos Pro"
        type: string # All args for Atmos Pro are strings
        required: false
        default: "false"

# Avoid running the same stack in parallel mode (from different workflows)
# This applied to across workflows to both plan and apply
concurrency:
  group: "${{ inputs.stack }}-${{ inputs.component }}"
  cancel-in-progress: false

permissions:
  id-token: write # This is required for requesting the JWT (OIDC) token
  contents: read # This is required for actions/checkout
  pull-requests: write # PR comments
  checks: write # This is required for Atmos set gha statuses
  statuses: write # This is required to post status checks back to the PR commit

jobs:
  atmos-plan:
    name: ${{ inputs.component }}-${{ inputs.stack }}
    runs-on:
      - "ubuntu-latest"

@Alexandre Feblot at the bottom of the run for Atmos, describe affected. Can you confirm that it uploaded affected stacks? Feel free to DM me any screenshots that might be considered sensitive.

There is no explicit message about a succesful upload. Just no more logs after the affected stack json dump. And the step succeeded.

Can you send me a current trace id?

I'am afraid there is no trace id I can get for this. The affected stack workflow completes successfully, then this, with no trace or additional info. Re-triggering it from the Atmos Pro dashboard gets simiilar results.

Oh, I mean from the atmos upload. You can see a trace id in one of the recent screenshots you shared

@Erik Osterman (Cloud Posse), I DM'ed you the entire log of that step, which is just the dump of the describe affected command. Given the 3rd screenshot, in the Atmos Pro dashboard, it seems the upload works fine. My understanding is the issues comes later, when Atmos Pro tries to trigger a plan job. But I have 0 info on what happens at that level.

Oh, the error above is almost always when the workflow being dispatched does not yet exist in the default branch. We are working on improving the error with more details of what went wrong.

Damned, indeed, they're not there yet. Thanks Just to be clear, are workflows ALWAYS taken from the default branch?

Yes, as a security precaution.

This is getting better, but still failing later on: the plan pipeline starts, runs the plan succesfully, and fails while trying to update Atmos Pro with the status (if I understand the error message properly). Do I miss another permission enabled in Atmos Pro besides "Affected Stacks Create" ?

...
Plan: 0 to add, 1 to change, 0 to destroy.
 ERRO  Pro API Error operation=UploadInstanceStatus request="" status=403 success=false trace_id=d87b2eca11d2f512280ec7c382090577 error_message="" context=map[]
🧪 ci is an experimental feature. Learn more <https://atmos.tools/experimental>
# Error

**Error:** failed to upload instance status failed to upload instance status API
response error: API request failed with status 403 (trace_id:
d87b2eca11d2f512280ec7c382090577)

This seems like a permissions issue

Indeed, fixed after having allowed "Create instance" and "Update instance"

Great! Is everything working now?

On the workflow perspective, yes, the tf apply one succeeded. I may not understand the dashboard though: The instance and stacks lists remain empty in the dashboard. All I can see there are workflow runs.

Ah yes, you will need a workflow that uploads the instances;

Thanks, let me look into this. I'm building a demo for our managers. I need all the bells and whistles I can get 🙂

We are also working to improve the error messaging

So, ran succesfully but: ℹ️ No Atmos Pro-enabled instances found; nothing to upload. I don't see anything about this concept in the doc and how to "atmos pro enable" a stack.

There's a known issue right now with list instances that should be fixed with the release of Atmos going out today

No planned date yet. When it's ready to shine.

Okay great. We'll get that released asap. Plus that should include another developer experience improvement and simplification for the workflows themselves that we can share once it's ready as well!

Hi, actually, I get the same

No Atmos Pro-enabled instances found; nothing to upload

with atmos 1.214.0

Have you enabled atmos pro for any component instances? https://github.com/cloudposse-examples/atmos-pro-example-advanced/blob/main/stacks/mixins/atmos-pro/default.yaml

Yes. My atmos-pro mixin seems correct (only drift detaction is currently disabled), and is included in a root _default.yaml that all stacks import indirectly.

Let's do this: atmos-pro.com/meet/onboarding

Thanks a lot. I'm currently struggling too with a legacy process of ours to provision roles for AWS auth with the GitHub provider. I anticipate some issues with this, so I'll book as soon as I've got those roles and been able to try using them.

Yes that will be a blocker