Oof, lots of incorrect information in this post, the two biggest offenders being:
You cannot use secrets in composite actions
You cannot conditionally execute steps in a composite action
I went ahead and created a contrived example of this to demonstrate why these are patently false.
I made two repositories, test-workflow, and test-action. The former contains a small workflow that calls the action in the latter. I have a secret configured in the test-workflow repository and I pass that secret to the action using the with block. That secret is received by one of the action's input parameters and is then "leaked" to stdout. You will notice in the action log that the "leaked" secret is indeed masked (the secret is also masked when "leaked" from a script)
Onto misconception #2. In the same action I described above, I created a step earlier in the action that will run only if an input value is set to World. But in the calling workflow, I set the value to "Wheeler". The step is supposed to print I won't run but I will try to say: Hello ${{ inputs.who-to-greet }}. where ${{ inputs.who-to-greet }} will be evaluated to the value I passed into the action. Seeing as it is not equal to World, the step isn't executed, and the lack of the above string can be observed in the action log; it would be executed before this step, but doesn't. Later in the workflow, I call the same action with the value set toWorld. This causes the conditional step to execute, displaying the string I mentioned earlier.
This conditional execution behavior is even documented in the documentation, so I would highly recommend reading it! And while the secrets masking of composite action's input values isn't explicitly mentioned, all it takes to figure this out is to create a small example like the one I made.
Overall, I would recommend that you fix this article to account for more correct information I laid out above. Reusable workflows have many limitations that aren't mentioned here, and their only real advantage is the ability to execute steps in parallel using jobs. Otherwise, they can't be located in their own private repositories and they don't play well with matrices.
@wheelerlaw Thanks for updates. I think this article was posted since April when GH Actions worked differently than now (Nov). Some points are still valid and some are no longer. GitHub Actions seems to have rapid evolution..
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Oof, lots of incorrect information in this post, the two biggest offenders being:
I went ahead and created a contrived example of this to demonstrate why these are patently false.
I made two repositories, test-workflow, and test-action. The former contains a small workflow that calls the action in the latter. I have a secret configured in the test-workflow repository and I pass that secret to the action using the
withblock. That secret is received by one of the action's input parameters and is then "leaked" to stdout. You will notice in the action log that the "leaked" secret is indeed masked (the secret is also masked when "leaked" from a script)Onto misconception #2. In the same action I described above, I created a step earlier in the action that will run only if an input value is set to
World. But in the calling workflow, I set the value to "Wheeler". The step is supposed to printI won't run but I will try to say: Hello ${{ inputs.who-to-greet }}.where${{ inputs.who-to-greet }}will be evaluated to the value I passed into the action. Seeing as it is not equal toWorld, the step isn't executed, and the lack of the above string can be observed in the action log; it would be executed before this step, but doesn't. Later in the workflow, I call the same action with the value set toWorld. This causes the conditional step to execute, displaying the string I mentioned earlier.This conditional execution behavior is even documented in the documentation, so I would highly recommend reading it! And while the secrets masking of composite action's input values isn't explicitly mentioned, all it takes to figure this out is to create a small example like the one I made.
Overall, I would recommend that you fix this article to account for more correct information I laid out above. Reusable workflows have many limitations that aren't mentioned here, and their only real advantage is the ability to execute steps in parallel using jobs. Otherwise, they can't be located in their own private repositories and they don't play well with matrices.
@wheelerlaw Thanks for updates. I think this article was posted since April when GH Actions worked differently than now (Nov). Some points are still valid and some are no longer. GitHub Actions seems to have rapid evolution..