[RFP] Small automation tasks, especially for newbies

[blag]

I'm opening this issue as a general Request For Proposals (RFP) to collect small and easy improvements that can be made to StackStorm, StackStorm-related projects, and StackStorm-related infrastructure. Most of the Senior Maintainers don't have time to automate these, and developing these tasks can largely be implemented by newbies who are trying to learn StackStorm while doing something to help the StackStorm community.

Please use this issue to identify easy things that people, especially newbies, can do to improve the infrastructure, tooling, integration, around StackStorm, and learn a bit more about StackStorm concepts, operation, and internals in the process.

Just to keep things more readable, please submit each request as a separate comment, and utilize GitHub's emoji reactions to 👍 or 👎 to individual requests.

If a request is controversial enough to you, please open a separate proposal issue specifically for it. For each request that gets turned into a proposal, I will update each request comment to point to their proposals. I'd like to avoid turning this RFP into a bunch of disparate discussions on individual proposals.

[blag]

Deploy packs using StackStorm itself, so we don't have to manually serialize all of the pack deployment steps ourselves.

This lets us make sweeping changes across all Exchange packs a lot easier, and it also bypasses the entire issue surrounding GitHub Personal Access Tokens, which expire after 1 year and are used to deploy packs. We have over 100 packs, so there's two packs each week whose tokens expire and have to be manually refreshed. If we centralize our deployment step, we can rely on StackStorm policy feature to serialize deployments for us, and we can use a single, protected credential (SSH key?) to clone and push updates to the index repository for all packs.

Steps to develop this:

1. Fork the StackStorm-Exchange/index repository into your own userspace
2. Setup an SSH key to push code to your index fork
3. Fork the ci repository and turn it into a pack (this is so we keep the deployment pack and the deployment script in the same place):

• Create a pack.yaml in the root
• Create an actions/ directory and an actions/worksflows/ subdirectory
• Create an action metadata YAML file actions/deploy.yaml with
  • runner type: orquesta
  • entry_point of workflows/deploy.yaml
• Create a workflow YAML file actions/workflows/deploy.yaml. This should follow what the deploy workflow is doing, see the AWS pack deploy workflow for reference. Note that you will probably have to use a randomly-generated temp directory on the StackStorm host (please make sure you clean it up!) and use the script and Python runners to get things working.
• Create a policy that restricts the ci.deploy to only run one one deploy step at a time with these settings (you'll have to add more data, like name, etc.):

  resource_ref: ci.deploy
  policy_type: action.concurrency
  parameters:
    action: delay
    threshold: 1

4. Spin up a StackStorm instance. If you don't know how to do this, use st2vagrant to get it running in a VM. You may also have to configure the policy backend to use.
5. Install your fork of the ci repo/pack
6. Configure it to use the GitHub SSH key for your index fork
7. Setup a StackStorm webhook rule to run the ci.deploy action, and have it pass the pack name as an action parameter. You should also include good diagnostic information, like the git branch/tag/commit hash (if there is one), the PR number (if there is one).
8. Use curl or httpie to mock a GitHub webhook request to StackStorm, and fix anything that breaks.
9. If you want to, you can setup ngrok.io in your VM, and configure a fork of a pack on GitHub to send a test request to your webhook endpoint.

Related proposal: #26

I suspect that this request is going to need its own proposal, so I've opened up #29 to track discussion there.

[blag]

Convert some Makefiles to use Python's Invoke project

Most of the Makefiles for StackStorm projects don't actually build any artifacts (literally the only thing make was designed to do) so they function more as a developer interface to do common tasks. In the st2 repo, we use make to do things like generate files, run lint tests, run unit tests, run integration tests, run packs tests, generate coverage results, and even push new versions to PyPI.

But treating make as a glorified task runner is overly complicated at best, and downright problematic at worst. Our Makefile is very complex even for seasoned developers who understand (most/some/enough) of Makefile syntax and common make intricacies.

Instead, we can use Python's Invoke project, which is just a task runner, to run our tasks, including their prerequisites. We can break up related tasks into their own modules so they are easy to find and extend without creating a single monolithic file, and we can use a tasks/__init__.py file, a very simple Makefile, and a bit of make magic to maintain 100% compatibility with the previous make targets. It's probably best to convert smaller, simpler StackStorm repositories over to Invoke first before (IF we ever) convert the main st2 Makefile, so here's a few candidate repositories with relatively small or straightforward Makefiles that would be pretty easy to convert to using Invoke:

• orquestaconvert
• orquesta
• StackStorm-Exchange/ci - see PR 79

There are two existing examples you can follow:

• PR 79 from StackStorm-Exchange/ci replaces a reasonably large and complex Makefile while breaking up tasks into their own Invoke modules and using tasks in __init__.py to maintain compatibility with the previous Makefile, as well as automatically creating a virtualenv and installing Invoke into it before calling it with the make target. Note that this needs to be updated to incorporate changes made to the Makefile since the PR was last updated.
• PR 4782 from st2 doesn't 100% work, but nearly replaces all of the make targets from the existing Makefile. Replacing some but not all of the make targets with Invoke tasks would be a nice "halfway" solution for this.

I suspect that this request is also going to need its own proposal, so I've opened up #30 to track discussion there.

[arm4b]

This is useful, comes as addition to working and encouraging StackStorm core work which is important as the ratio of reported Issues, Bugs, PRs, development activity is in a really bad shape there and it's a bigger danger for the project.

Project Governance https://github.com/StackStorm/st2/blob/master/GOVERNANCE.md#how-to-start-contributing lists the following useful contribution activities:

• triaging issues with status: to be verified will help you to get familiar with the project functionality
• working on issues tagged as good first issue
• bugs are very important to address and will help you to get more familiar with the codebase
• enhancements marked with refactoring tag
• any documentation improvements are always appreciated
• perform code reviews on other's pull requests. Second pair of eyes and a few cycles of manual testing can help to prevent bugs early
• join the #development channel in StackStorm Slack for more pointers from the current Maintainers