You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am trying to use the scaffolder action for http request to trigger external API calls to AWX in our organization, in order to launch workflow_templates dynamically with the form inputs provided by the users in the Red Hat Developer Hub GUI (RedHat's Backstage)
Expected Behavior
Configure the specific parameters into the required parameters of the roadiehq-http:backstage:request in my software template definition, as well configuring appropriate proxy settings in the app-config.yaml, and upon user form inputs a POST method API call will happen to the AWX external API that will inturn launch a workflow_template
Current Behavior
Doing all that was said above leads me to receiving a Status code of 301 (permanent redirect) response code, leaving me stuck with a "successful" action step, but in reality the workflow_template was never triggered, and the POST method call never reached the AWX api.
I looked abit the in the code of the plugin, fairly simple and clean
Maybe there needs to be some sort of handling for redirect response codes?
something like fetch(url, { method: 'POST', redirect: 'follow'})
Context
Red Hat Developer Hub (v1.3.1) comes pre-installed with the roadiehq-http:backstage:request scaffolder action (v4.3.2), so I just followed the official documentation of roadie https://roadie.io/backstage/plugins/scaffolder-http-requests/ for the input parameters
I am also working on an airgapped self-managed Openshift to host the Red Hat Developer Hub, not sure if that makes a difference
I'll be glad for your assistance. Maybe i missed the mark completely, i am quite new to Backstage and all of the plugin architecture in it. Thanks in advance
I am trying to use the scaffolder action for http request to trigger external API calls to AWX in our organization, in order to launch workflow_templates dynamically with the form inputs provided by the users in the Red Hat Developer Hub GUI (RedHat's Backstage)
Expected Behavior
Configure the specific parameters into the required parameters of the roadiehq-http:backstage:request in my software template definition, as well configuring appropriate proxy settings in the app-config.yaml, and upon user form inputs a POST method API call will happen to the AWX external API that will inturn launch a workflow_template
Current Behavior
Doing all that was said above leads me to receiving a Status code of 301 (permanent redirect) response code, leaving me stuck with a "successful" action step, but in reality the workflow_template was never triggered, and the POST method call never reached the AWX api.
Steps to Reproduce
template.yaml
name: ...
action: http:backstage:request
input:
method: POST
path: proxy/awx-api/workflow_job_templates/2050/launch
headers:
Content-Type: application/json
Authorization: 'XXXXXXX`
body:
extra_vars:
......
app-config.yaml
proxy:
endpoints:
'/awx-api':
target: https://awx.com/api/v2
changeOrigin: true
secure: true
credentials: dangerously-allow-unauthenticated
Possible Solution
I looked abit the in the code of the plugin, fairly simple and clean
Maybe there needs to be some sort of handling for redirect response codes?
something like
fetch(url, { method: 'POST', redirect: 'follow'})
Context
Red Hat Developer Hub (v1.3.1) comes pre-installed with the roadiehq-http:backstage:request scaffolder action (v4.3.2), so I just followed the official documentation of roadie https://roadie.io/backstage/plugins/scaffolder-http-requests/ for the input parameters
I am also working on an airgapped self-managed Openshift to host the Red Hat Developer Hub, not sure if that makes a difference
I'll be glad for your assistance. Maybe i missed the mark completely, i am quite new to Backstage and all of the plugin architecture in it. Thanks in advance
Your Environment
Red Hat Developer Hub
version: 1.3.1@backstage
version: 1.29RoadieHQ http:backstage:request scaffolder action
version: 4.3.2The text was updated successfully, but these errors were encountered: