Update the set-output command

[rvanderlinden]

Hi! 👋🏽

Is your feature request related to a problem? Please describe.
We are receiving deprecation warnings for this action because the set-output command is deprecated and will be disabled in the near future. If the deadline is not postponed, this functionality and the action itself may stop working on 31st May 2023. I have outlined the deprecation warning below.

Warning: The set-output command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

Describe the solution you'd like
Please update this action to use environment files instead of set-outpout as outlined in this guide.

Thanks 😄 !
Roland

[CamiloGarciaLaRotta]

the docs say we should update @github/core to at least 1.10.0 🤔 that seems to already be the case. @rvanderlinden mind pointing me to where you see that we are still using the old set-output?

Edit: here's the new release v1.6. Let me know if this solves the issue for you!

[rvanderlinden]

@CamiloGarciaLaRotta Thank you for the quick reply and new release.

Unfortunately this issue has not been resolved. At first I was targeting the major version CamiloGarciaLaRotta/watermelon-http-client@v1. To be sure I also tried out the explicit v1.6 CamiloGarciaLaRotta/watermelon-http-client@v1.6. Both with the same result, as seen in the screenshot below:

I would like to help out investigating this issue, but it has to wait until my planning allows it.

[rvanderlinden]

In case it matters, this is our setup for posting a message to Slack:

    - name: Slack test message
      id: slackrequest
      uses: CamiloGarciaLaRotta/watermelon-http-client@v1.6
      with:
        url: 'https://slack.com/api/chat.postMessage'
        method: post
        headers: '{
          "Authorization": "Bearer ${{ secrets.SLACK_BOT_TOKEN }}", 
          "Content-Type": "application/json" 
        }'
        data: '{ 
          "channel": "<redacted slack channel id>", 
          "username": "${{ github.workflow }}",
          "icon_url": "<redacted icon url>",
          "text": "Test message to slack."
        }'

[CamiloGarciaLaRotta]

Happy to 🍐with you or review any PR that you soon for this issue 🙃

In the meantime I'll try to reproduce on a dummy repo.

---

Edit: Ok I was able to reproduce and I'm baffled 😬 watermelon is currently at @actions/core 1.10.0, which should have the fix already: actions/toolkit#1218 (comment)

watermelon-http-client/package.json

Line 28 in d8e8acc

"@actions/core": "^1.10.0",

AFAICT it's the only dependency that does set-output. I don't think axios and node-notifier would be aware of GH Actions

---

The plot thickens! I found this under our /dist/index.js: we somehow still have an outdated setOutput func 🤔

function setOutput(name, value) {
    process.stdout.write(os.EOL);
    command_1.issueCommand('set-output', { name }, value);
}

---

Quite an adventure 😅 found the root cause: my release pipeline is faulty. I was not generating a new /dist/index.js whenever there were changes to TS code! I am currently working through all these compiler warnings. Will update once I wrap them up

[CamiloGarciaLaRotta]

🙇🏽‍♂️ @rvanderlinden mind testing your repo's workflow with the latest version: v1.7

steps:
    - uses: CamiloGarciaLaRotta/watermelon-http-client@v1.7

[rvanderlinden]

@CamiloGarciaLaRotta That was harder than expected, good find!

I have tested @v1.7 and the warnings no longer appear. Looks like this issue is resolved, thank you! :)

It looks like @v1 still has the warnings. I assume this either requires a manual delivery-step from you or perhaps it's a caching issue that will resolve in due time?

[CamiloGarciaLaRotta]

🙃 most likely caching, because v1 should already take the latest 1.* Release

[rvanderlinden]

Thanks again!

[rvanderlinden]

Hi @CamiloGarciaLaRotta! To get back to my question regarding the @v1 not behaving similarly to @v1.7: I just found out that the actual v1 tag has to refer to the latest release commit in order for version overriding to work. So right now, I think the @v1 does actually use the older v1.4 tag (see screenshot) and not the v1.7 tag, which we both presumed would happen automatically. I will be referencing v1.7 from here on out, perhaps this is something you could update or outline in the readme :)

See also this thread: https://github.com/orgs/community/discussions/48058#discussioncomment-5055159.