Skip to content
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

deployment-action vs deployment_action #100

Closed
luke-denton-ofx opened this issue Jan 13, 2025 · 3 comments
Closed

deployment-action vs deployment_action #100

luke-denton-ofx opened this issue Jan 13, 2025 · 3 comments
Labels
bug Something isn't working

Comments

@luke-denton-ofx
Copy link

Thanks for your work regarding comment customisation!

I was playing around with it today, and my comment kept getting skipped. I had the if statement on it as described in the documentation of this action, but every time, the comment step wouldn't run.

After a very long day of debugging, in order to get it to work, I had to update it to be:

if: (steps.deploy-preview.outputs.deployment_action == 'deploy' || steps.deploy-preview.outputs.deployment-action == 'deploy') && env.deployment_status == 'success'

Checking just *.deployment_action and deployment_status would not work, and checking just *.deployment-action and deployment_status wouldn't work. *.deployment_action and *.deployment-action needed to both be in the same conditional.

I was able to replicate this in a new rep: https://github.com/luke-denton-ofx/test-actions

Any idea what might be going on?

@rossjrw rossjrw added the bug Something isn't working label Jan 13, 2025
@rossjrw
Copy link
Owner

rossjrw commented Jan 13, 2025

The output is deployment-action, not deployment_action.

Looking at your logs, that steps debug step is really handy, thanks for adding it.


For my own reference: it looks like you've got one feature branch, so to speak, and have created a PR for each commit on it - so PR 7 contains all the commits for PRs 1-6, etc. The workflow logs for the commits in PR 7 each show that workflow as having been run during its respective later PR - e.g. the log for 5d6b546, the first commit, appears as a green tick on PR 7 but was actually run under PR 2 (and there's also a workflow run for it under PR 1, because PR 1 and PR 2 contain the same commit). Also worth bearing in mind that clicking the green tick takes you to the latest check for that commit, even if it wasn't in the current PR, which for most previous commits is the PR closed event that removes the preview.

Taking a look at luke-denton-ofx/test-actions#7, which we know worked:

  • The latest workflow run for PR 7 is https://github.com/luke-denton-ofx/test-actions/actions/runs/12741120767, which was on the opened event, so we know that the PR was opened after the commit was committed
  • Commit is luke-denton-ofx/test-actions@b015643
  • The logs say deployment-action: deploy, which is what we expect
  • Comment condition is (steps.deploy-preview.outputs.deployment-action == 'deploy' || steps.deploy-preview.outputs.deployment_action == 'deploy') && (env.deployment_status == 'success') (TRUE || FALSE) && TRUE → TRUE
  • Comment was posted

Comparing to one that I assume not to have worked, luke-denton-ofx/test-actions#6:

Looking at luke-denton-ofx/test-actions#5, which does not contain a PR comment:

  • There are 3 workflow runs for PR 5:
  • Commit is still e83e528, so no changes to the workflow compared to PR 6
  • The logs say deployment-action: deploy
  • However, env.deployment_status is skipped, because the preview step had no new changes to deploy - presumably because it already did so in the opened event
  • Comment condition is steps.deploy-preview.outputs.deployment-action == 'deploy' && (env.deployment_status == 'success') TRUE && FALSE → FALSE
  • No comment was posted
  • Looking now at the opened workflow, which I am expecting to have created a preview and posted a comment (which it demonstrably did not):
    • The latest commit is luke-denton-ofx/test-actions@b46e1da, one before e83e528 - this makes sense because the addition of e83e528 is what created the synchronize event
    • The condition is steps.deploy-preview.outputs.deployment_action == 'deploy' && (env.deployment_status == 'success') FALSE && TRUE → FALSE
    • No comment was posted

So in summary:

  • The condition for your comment depends on both the action being deploy and the deployment succeeding.
  • JamesIves/github-pages-deploy-action is used under the hood which only sets env.deployment_status to success if there were any changes to commit to the preview, otherwise it sets it to skipped.
  • You were normally pretty diligent about resetting this each time you tried something by creating a new PR, except for one time in PR 5 where you fixed the condition without also changing the dummy file, so that condition didn't pass even though it was correct.

steps.deploy-preview.outputs.deployment-action == 'deploy' && env.deployment_status == 'success' is the correct condition to use. If the deploy is skipped, it normally shouldn't matter because it will only be skipped if the thing it's trying to deploy is already there, so this sort of situation would only happen if you were messing with the workflow conditions, which would only happen during this kind of testing. You could use just steps.deploy-preview.outputs.deployment_action == 'deploy' if you always want a comment to be posted even if nothing is deployed.

I'm going to close this issue but feel free to respond and I'll do my best to help. We can reopen it if we discover a bug.

@rossjrw rossjrw closed this as completed Jan 13, 2025
@luke-denton-ofx
Copy link
Author

Thanks for your in depth review of my repo Ross, I really appreciate it.
I must admit, I've managed to confuse myself now as to what I actually was testing with that repo, but at least I know for certain that it's deployment-action.

This will need to be updated in the README docs, as they currently say deployment_action. The only reason I even tried deployment-action is because I could see that in the code diff, but wasn't sure if Github Action was doing something magic to make deployment-action available as deployment_action.

I'll continue to play around on my end and see if I can get a better sense of why I regularly don't get a comment posted (due to the if condition), and will create a better set of PR's to demonstrate

@rossjrw
Copy link
Owner

rossjrw commented Jan 14, 2025

This will need to be updated in the README docs, as they currently say deployment_action

Unbelievably embarrassing... fixing immediately (thank you!)

I'll continue to play around on my end and see if I can get a better sense of why I regularly don't get a comment posted

Sounds good. If you can find an instance where the action resolves to 'deploy' and the JamesIves build step does have something to push (env.deployment_status is success instead of skipped, feel free to raise it as a new bug or comment here / in a discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants