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

Add AdHoc step implementer that can be used to run a command or script from any step #291

Open
wants to merge 17 commits into
base: main
Choose a base branch
from

Conversation

RyanMillerC
Copy link
Member

Purpose

Implements #131. Adds ad-hoc shared step implementer that can be used to run a command or script from any step.

Breaking?

No

Integration Testing

I did not do integration testing. I did add unit tests for new code though! 😎

@itewk
Copy link
Contributor

itewk commented Sep 13, 2022

Two questions:

if it’s going to run as bash shouldn’t it be called the Bash step or something?

what’s the point of this. If there is no inputs or outputs to normalize and be able to parse results from why call the PSR at all, why not just call the script direct? The intent of the PSR (was) to be able to abstract common API interactions by normalizing inputs and outputs. But since this allows someone to run anything there is nothing to normalize that can then be consumed by future steps.

@dwinchell
Copy link
Contributor

@itewk I think it's useful and could be made useful. Right now it lets you:

  1. reuse the psr-based workflow definition. You don't have to tinker with minimal.groovy to run some one-off that doesn't have a step implementer. That's especially useful if you're prototyping something.
  2. obfuscate outputs
  3. use the standard reporting, including the stdout as an artifact

It could also be enhanced to do things like
4) pass in values from previous steps, like version numbers or generated urls

Granted, writing your own step implementer in python does all that, but people who are prototyping or who aren't developers might not want to do that.

@dwinchell
Copy link
Contributor

@itewk As far as calling it "AdHoc" instead of "Bash" ... some people feel opposed to the idea of encouraging users to use PSR without writing step implementers in python. Calling it AdHoc helps to communicate that they are forgoing some of the benefits of writing your own step implementer.

@itewk
Copy link
Contributor

itewk commented Sep 30, 2022

@dwinchell okay on all accounts.

@codecov
Copy link

codecov bot commented Oct 12, 2022

Codecov Report

Merging #291 (9f3736b) into main (bbc65e5) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main      #291   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          106       107    +1     
  Lines         4317      4351   +34     
=========================================
+ Hits          4317      4351   +34     
Flag Coverage Δ
pytests 100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...s_step_runner/step_implementers/shared/__init__.py 100.00% <100.00%> (ø)
...gos_step_runner/step_implementers/shared/ad_hoc.py 100.00% <100.00%> (ø)
...os_step_runner/step_implementers/tag_source/git.py 100.00% <0.00%> (ø)
..._runner/step_implementers/generate_metadata/git.py 100.00% <0.00%> (ø)
...implementers/generate_metadata/semantic_version.py 100.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@RyanMillerC
Copy link
Member Author

@dwinchell Updated to use shell util instead of bash (removed bash all together). Should be good to go.

@RyanMillerC RyanMillerC requested a review from dwinchell October 24, 2022 15:45
This executes the given command but doesn't do anything with the
results. Also, if the command writes to stderr it comes out as stdout.
Not sure if that is a pattern of PSR or if that needs addressed. 🤷
This matches the pattern of the io.npm module.
These tests are copies of the tests for utils.npm.
If the try block fails, the return code was not being set. The return
code is in the output, so providing it is redundant.
The NPM module had this so I'm adding it. Seems inconsistent on what
classes call their parents __init__ and which don't. Not sure if the
pattern changed or there is some other reason. 🤷
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants