Feat | add github action with input flags (WIP)#342
Feat | add github action with input flags (WIP)#342jamesoneill997 wants to merge 1 commit intodag-andersen:mainfrom
Conversation
fix: update default value to valid string fix: run workflow on ubuntu latest on all pulls fix: workflow syntax fix: formatting for workflow fix: more formatting fixes fix: appease naming conventions fix: remove erroneous quotes fix: fixing quotes fix: default name for linux fix: begin next steps fix: use splat to view inputs fix: splat the array type fix: view first elem fix: syntax fix: nested array fix: use fromJSON for input fix: proper deref fix: to instead of from fix: show bash version, echo version map param fix: use array instead of json fix: parameter formatting, add filtered json params fix: filtering syntax fix: more formatting fixes, remove defaults, add test values to workflow fix: print out keys and vals in default sorted order fix: construct options string from input fix: variable reference fix: formatting fix: convert json to bash array fix: add debug logging fix: formatting fix: add quote stripping fix: escape double dash fix: formatting fix: jq arg formatting fix: formatting fix: add logging fix: assignment operator fix: add required parameters fix: add documentation
|
Hi @jamesoneill997, Thank you so much for bringing this up - and great to see you found the related issue from half a year ago! I encourage others to join the conversation if they have opinions on the topic :) Today I would still make the same arguments for and against a GitHub Action as I did back then. Regarding maintenance: building new features for That said, if you or someone else wants to maintain it as a standalone action, I would very much welcome that and happily link to it from the docs! 🚀 Let me know what you think 🔥 |
|
That's totally fair @dag-andersen , thanks for getting back to me. I'm happy to try to put something together for a standalone action and do my best to maintain it. I'm also a little tight on schedule time at the moment. However, for me to maintain an action for this probably wouldn't be massively time-consuming. Realistically, the action will only ever act as a wrapper for the tool, so the only thing that would need to be configured in a standalone repo is a release process, some form of dependency manager/bot that would create a PR to update the default version when you perform a release, and then a bit of work to add new flags and bump versions appropriately whenever they're added. The bulk of the work for the wrapper is in this PR (the only real challenge being mapping args to flags). So provided I could just cut and paste this approach into a standalone repo, then I should be able to keep on top of it. I'll get working on creating a repo and configuring what's required, I'll pop a link in here once it's g2g. Thanks again for your input and general hard work creating this tool 🙏 |
2 participants
Addresses: #227
Hey there @dag-andersen, I have been playing around with creating a composite action that would allow for the use of native GitHub Actions inputs and handle the installation of the tool in a more "actiony" way.
This is very much a WIP, but I just wanted to open up a PR with what I've got so far to see if there are any strong preferences on how this would be implemented/maintained.
Basically, it is just parsing the inputs object with jquery, with the convention being that for each flag, there is a corresponding github action input that is the name of the flag minus the
--. It takes some platform-specific parameters to determine what to install, and constructs a string of flags and options from the parsed inputs.Usually actions have their own release schedule and it isn't unusual for them to live in their own repositories. However, it is possible for them to co-exist, but it does just add another thing to maintain within the main project. In other projects, I've used semantic release + conventional commits to manage action versions separate to the package release version. However, as the package itself seems to be very active in its release schedule, it would likely require fairly active maintenance to make sure any new flags are available.
With all of that said, I'm not sure whether it makes sense to have this in a separate repository that has its own version and release mechanism going on, or whether you'd be wanting and willing to pull this into the main repo and include the maintenance as part of the package development.
Again, this is very much a first draft that could be fleshed out a lot more, but I just wanted to open up the discussion to see what you think. I'm happy to tweak things and maintain it as a standalone action to the best of my ability, but I'm also interested to see what you think.