[MAINT] Convert legacy Schema Migrations to use StateUpgraders

[deiga]

Supersedes #3018

---

Before the change?

• Schema Migrations used MigrateState which is from 0.11 of the SDK
• Converted resources:
  • github_actions_organization_secret
  • github_actions_secret
  • github_repository_webhook
  • github_repository

After the change?

• Schema Migrations use StateUpgraders which is the default since 0.12 of the SDK

Pull request checklist

• Schema migrations have been created if needed (example)
• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes
• No

---

[github-actions]

👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labeled with Status: Up for grabs. You & others like you are the reason all of this works! So thank you & happy coding! 🚀

[stevehipwell]

Could we move the migration code into the resource files instead of having it in separate files which makes it significantly harder to reason about?

[nickfloyd]

Could we move the migration code into the resource files instead of having it in separate files which makes it significantly harder to reason about?

We can definitely do that - I'd recommend that we follow up with changing the existing ones as well so that we have a consistent pattern.

[stevehipwell]

@nickfloyd I think this PR is modifying all of the existing ones, so I was meaning for all migrations to be located next to the relevant schemas.

[nickfloyd]

@stevehipwell That makes so much more sense... thank you for the clarity.

[deiga]

@nickfloyd @stevehipwell I'm honestly not sure about merging the migration files with the resource files

Some of these migration files are very long and since they contain Schemas at specific points in time it could make it confusing to have multiple schema in the same file. Or would we keep the schemas still in separate files and only move the state upgrade functions to the resource files?

[stevehipwell]

What about adding schema files with the same name as the primary files and then adding a schema suffix so they're at least located next to each other? For example github_resource_foo.go & github_resource_foo_schema.go

[nickfloyd]

@stevehipwell I'm wondering if this would be a good move for 7.x. I really like the idea of a related grouping so for instance our protocol would be:

github_[resource]_[function].go

So, given something like: branch_protection, like you were sketching out, you'd have:

• github_branch_protection_migrate.go
• github_branch_protection_resource.go
• github_branch_protection_resource_test.go
• github_branch_protection_data_source.go
• github_branch_protection_data_source_test.go

Is that what you were thinking? If so I can write up an issue for us to rework all of that.

[deiga]

@stevehipwell Something like this? 710d9b8 (#3065)

[stevehipwell]

@deiga do you mean the code or file paths?

@nickfloyd for v7 I'd suggest aligning to a more idiomatic approach like below. But for now I'd really like to see the migration code moved as it's all being modified.

• internal/provider/data_repository.go
• internal/provider/data_repository_schema.go
• internal/provider/data_repository_test.go
• internal/provider/repository.go
• internal/provider/repository_schema.go
• internal/provider/repository_test.go

[deiga]

@stevehipwell Both? Just wanted to double check if this close enough to what you had in mind, before I do the same change for every migration file

[stevehipwell]

@stevehipwell Both? Just wanted to double check if this close enough to what you had in mind, before I do the same change for every migration file

I was on my phone so it was hard to figure out what had changed.

OK, how about github/resource_github_actions_secret_migration.go (& github/resource_github_actions_secret_migration_test.go) with the migration functions and the schemas in the one file? I think this will meet my desire for keeping the code together without adding additional complexity to the main files. Also after thinking it through carefully I realized that once the migration has happened the code is effectively meaningless so should be kept out of the way for general readability.