-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
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
Support for Organizational-Level Action Variables in Payload Parsing #330
Comments
Hey @hemupadhyay26 👋 At the moment it's unclear why this might be happening, but I do agree that variables stored at an organization level should be used in payloads! Can you share the Marking this as a |
This is the scenario I was using to run my workflow |
@hemupadhyay26 Thanks for sharing this one! Something in the workflow is standing out to me that might be causing this, along with how templated variables are replaced in workflows 👀 When using the Using a similar example, that means the following workflow file input: - name: Post to a Slack channel
uses: slackapi/slack-github-action
env:
SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}
with:
payload: ${{ vars.DETAIL_SLACK_NOTIFICATION }} Would expand to something like: - name: Post to a Slack channel
uses: slackapi/slack-github-action
env:
SLACK_BOT_TOKEN: "xoxb-example"
with:
payload: "GitHub Action build result: ${{ job.status }}" Which would then send that payload text as is! 📣 To instead wait for this replacement to happen from within the action, you'll have to use This might not be an ideal workaround, but I believe you can write a temporary file using the same |
@zimeg I have tried to make the file in the workflow using the |
I think we could achieve by adding the parsing when we get data through the payload as well so we could resolve that issue |
@hemupadhyay26 Great to know this is working as expected with I agree that the runtime edits to the repository are not be ideal, but I'm wondering if another way exists to parse these variables in a 📚 Some background contextWe've found strangeness in the parsing logic from within the action code where "...only values of the An option to skip these replacements for files was added with the ⚙️ Some thoughtsAt the moment I'm hesitant to expand what we're parsing since this has caused confusion before, but now could be a good time to revisit the scope of what One quick concern for this would be a meaningless Edit: This input could be string though! We could do additional parsing if it's - uses: slackapi/slack-github-action
with:
payload: ${{ vars.DETAIL_SLACK_NOTIFICATION }}
payload-templated: true I'm open to continuing this discussion here (though my responses will lag these next few weeks), but believe this could be related to #312 🚀 Before considering those wider changes, I'm also wondering if you can share more about |
Description
We are currently managing our GitHub Action payloads at the organizational level. However, we've encountered an issue where the action variables are not being correctly parsed or passed when generating the payload. This results in the payload not being fully supported, leading to errors when actions run.
To address this, we need to ensure that any payload created using organizational-level action variables is fail-safe and parsed correctly when received.
Problem Statement
Organizational Action Variables: We aim to define and use action variables at the organizational level, but the variables are not being correctly processed when generating payloads.
Payload Parsing: The action payload does not fully parse when passed, leading to incomplete or incorrect data being sent.
Proposed Solution
Acceptance Criteria
Additional Context
This enhancement will improve the robustness of our CI/CD pipeline by ensuring that organizational-level configurations work seamlessly with GitHub Actions.
This format should make it clear and actionable for the development team!
What type of issue is this? (place an
x
in one of the[ ]
)Requirements (place an
x
in each of the[ ]
)The text was updated successfully, but these errors were encountered: