[FEATURE] Managing Reusable GitHub Actions

[peternied]

Is your feature request related to a problem?

Lots of teams have to adopt very similar workflows for things such as:

• Setting up backwards compatibility tests
• Installing a plugin on an OpenSearch instance

What solution would you like?

GitHub Actions support Composite actions [1], there has already been adoption in non-reusable ways [2]. The main limit is how to consume these actions in the OpenSearch-Project.

Proposal One - Single Project-Wide 'Actions' Repository

Create a new repository where all actions are added like ./install-opensearch/action.yml these would be referenced in an GitHub Action like uses: opensearch-project/actions/install-opensearch@install-opensearch-v1.

Pros:

• All the different actions that are reused by OpenSearch-Projects are in one location, making discovery easier, its clear where new actions should be created.

Cons:

• Every time a new action is added or one is updated, a new tag should be created for security purposes. This results in many many tags being created and can be messy.
• Need a maintainer(s) for the repository

Proposal Two - Reuse OpenSearch-Build Repository

Similar to proposal one, but instead reuse the OpenSearch-Build repository. This is already a focal point for many build/test workflow related tasks.

Pros:

• Already has established maintainers
• Already known to be a place for contributions from members of the project

Cons:

• Further overloads the use of OpenSearch-Build
• Might need to partition GitHub actions CI tests separately from other systems.
• Requires more release tagging to follow GitHub Action best practices

Proposal Three - Create a repository for each action

Instead of centralization actions, instead build them out into separate repositories

Pros:

• Separation of concerns, actions and support systems are direction proportional to effort
• Can be shipped into the GitHub Actions marketplace for discoverability and reuse

Cons:

• Non-trivial process to create new repositories in OpenSearch-Project
• Ensuring maintainer-ship

Proposal Four - Create personal repositories for actions

Similar to proposal three, but make them as personal projects

Pros:

• Fastest time from inception to availability
• Can be adopted into OpenSearch-Project if there is a desire

Cons:

• Personal projects look less supported than official OpenSearch-Project repos
• Other than copypasta hard to discover projects specific actions

Do you have any additional context?

• [1] https://docs.github.com/en/actions/creating-actions/creating-a-composite-action
• [2] https://github.com/opensearch-project/security-dashboards-plugin/blob/main/.github/actions/install-dashboards/action.yml

[peternied]

I am going to keep making more personal repositories for common actions, but it would be nice if we had a perspective on actions specific for OpenSearch-Project

e.g.

• https://github.com/peternied/download-file
• https://github.com/peternied/action-sleep
• https://github.com/peternied/get-opensearch-version

[peternied]

@bbarani @VachaShah @dblock What do y'all think?

[dblock]

I think opensearch-github-actions is a bit of a "technology" catch-all vs. a purpose catch-all. Typically GHA live in their own repos each and release, e.g. https://github.com/dblock/create-a-github-issue. Is there a reason not to author a proper opensearch-install GHA in its own repo with its own release lifecycle?

For completeness, a lot of build infrastructure in OpenSearch and OpenSearch Dashboards inherits scripts (gradle or otherwise) from the core repos. Is there an option to put shared actions into OpenSearch and OpenSearch-Dashboards repos? Similarly, is https://github.com/opensearch-project/opensearch-build-libraries another option?

[peternied]

FYI @cwperks