We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A customer using the ArgoCD deploy instructions - https://docs.opslevel.com/docs/argocd - was getting a very strange error
{"status":422,"error":"Unprocessable Entity"}
Running the same command locally (must use -f . for it to not hang)
-f .
opslevel create deploy -i "https://app.opslevel.com/integrations/deploy/XXXXXX" -s "report_deploy_github_action" -f .
nets the response
Successfully registered deploy event for 'my_service_alias'
But we were able to reproduce it using a job in k8s
apiVersion: batch/v1 kind: Job metadata: name: report-deploy spec: template: spec: containers: - name: main image: public.ecr.aws/opslevel/cli:v2024.10.11 command: - "opslevel" - "create" - "deploy" - "-i" - "${OPSLEVEL_INTEGRATION_URL}" - "-s" - "my_service_alias" env: - name: OPSLEVEL_INTEGRATION_URL value: "https://app.opslevel.com/integrations/deploy/XXXXXXXXXXX" restartPolicy: Never backoffLimit: 2
The above will produce the error
BUT EVEN MORE BEWILDERING if we remove the -i flag from the invocation it works
-i
apiVersion: batch/v1 kind: Job metadata: name: report-deploy spec: template: spec: containers: - name: main image: public.ecr.aws/opslevel/cli:v2024.10.11 command: - "opslevel" - "create" - "deploy" - "-s" - "my_service_alias" env: - name: OPSLEVEL_INTEGRATION_URL value: "https://app.opslevel.com/integrations/deploy/XXXXXXXXXXX" restartPolicy: Never backoffLimit: 2
The text was updated successfully, but these errors were encountered:
No branches or pull requests
A customer using the ArgoCD deploy instructions - https://docs.opslevel.com/docs/argocd - was getting a very strange error
Running the same command locally (must use
-f .
for it to not hang)nets the response
But we were able to reproduce it using a job in k8s
The above will produce the error
BUT EVEN MORE BEWILDERING if we remove the
-i
flag from the invocation it worksnets the response
The text was updated successfully, but these errors were encountered: