[Release Improvements] Migrate actions from dbt-adapters

[mikealfare]

Short description

Migrate actions from dbt-adapters and establish a style standard and best practices guide for both action structure and repo structure.

Context

We need to perform regular automation across open source repos. When dbt-adapters was setup, new actions were hosted there because they needed to support hatch. We should migrate those actions to dbt-labs/actions so that we don't have two sources of truth.

Given the size of the migration, this is a good time to consider establishing a style standard and best practices.

A draft of these changes can be seen on https://github.com/dbt-labs/actions/tree/add-hatch-actions. This draft makes a lot of assumptions, combines several changes in parallel, and has not been tested; however it demonstrates the goal conceptually.

Objectives

• We have a central repository of robust and reusable actions
• We have a style guide that removes individual preference debates from PR reviews
• We have a best practices guide that can be used prior to requesting a PR review

PRs

Beta Give feedback

1. ADR-0001: Style guide #191
   +0
   
2. ADR 0002: Best practices guide #206
   +0
   
3. Add changie/changelog/create action #192
   +0
   
4. Add changie/changelog/view action #193
   +0
   
5. Add github/branch/create action #194
   +0
   
6. Add github/branch/edit action #195
   +0
   
7. Add github/commit/create action #196
   +0
   
8. Add github/commit/view action #197
   +0
   
9. Add github/release/create action #198
   +0
   
10. Add github/release/edit action #199
    +0
    
11. Add github/release/view action #200
    +0
    
12. Add github/team/view action #201
    +0
    
13. Add hatch/artifact/create action #202
    +0
    
14. Add hatch/environment/create action #204
    +0
    
15. Add hatch/version/edit action #203
    +0
    
16. Add pypi/release/create action #205
    +0
    

Testing

• New actions are tested against another repo prior to merging

Security

Our actions have access to credentials and get run indirectly by third party contributors. We should consult Security for the best practices guide.

Docs

Each action should have some level of documentation explaining how to use it and why certain decisions were made if they are not intuitive. This should be in the same directory as the action.

We might want to consider sharing the guide and practices in dbt-labs/oss-at-dbt.

Some draft work has been done in this PR: #172

Consequences

Pro's

• finding and using an action will be easier
• standards make for less human error and easier maintainability

Con's

• using these actions will require a migration in all dependent repos