Implement Sync Beta Group Commands

[DechengMa]

Implement basic sync beta group command.

• Delete local group files -> request to remove groups in server
• Create local group files -> request create groups in server
• After create -> pull back and sync local
• Edit local group files -> update server groups
• Wrap up and restructure codes
• Apply new file system on it
• Refactor file structure and remove duplicate data

📝 Summary of Changes

Changes proposed in this pull request:

• Add let id: String? field to Beta Group model. I know we don't want to do this but it's a must coz two groups can have the same name.
• Add var testers: [String] to Beta Group for storing tester emails
• Make BetaGroup extend to Equatable, Hashable for comparing in Set, to SyncResultRenderable for rendering dry run and sync result, to FileNameGettable for generating a beatified filename (a String extension was made for snakeCased filename).
• Create SyncResultRenderer for printing sync and dry run result
• Create enum SyncStrategy for both rendering result and handle the update.
• Create protocol ResourceFolderManagerand BetaGroupFolderManager, for managing folders and group files.
• Tweak ListBetaTestersOperation and create UpdateBetaGroupOperation. Create service function pullBetaGroups, updateBetaGroup, deleteBetaGroup.
• Implement SyncBetaGroupsCommand which contains PullBetaGroupsCommand and PushBetaGroupsCommand.

⚠️ Items of Note

• When edit file to change group, only particular field are editable: for a beta group, only name, public link, link limit, link enabled can be changed (according to API), and if others are changed, when push it will have no effect. So this means the user must have some instructions.

🧐🗒 Reviewer Notes

💁 Example

Usage:

asc testflight betagroup sync pull [--output-path <output-path>]
asc testflight betagroup sync push [--input-path <input-path>] [--dry-run]

--output-path and --input-path is a folder path.

CLI will go through all the files in that folder and find file with a suffix of yml and read it as a beta group file.

Sample Output:

TODO

Sample file structure

TODO

🔨 How To Test

asc testflight betagroup sync pull

asc testflight betagroup sync push --dry-run

asc testflight betagroup sync push

How to

Note: Please run pull first to get server groups and testers before run push

Create a new group via sync:

1. Create a file, name it whatever you like in folder ./config/betagroups(or the input folder path), suffix must be yml
2. Put some basic group info in it, eg

app:
  bundleId: com.example.foo // MUST HAVE
groupName: testgroup // MUST HAVE, MUST UNIQUE (please don't create group with the same name in same app)
publicLinkEnabled: false
publicLinkLimit: 5
publicLinkLimitEnabled: false

3. Run command asc testflight betagroup sync push

Delete a group

1. Delete the group file in folder
2. Run command asc testflight betagroup sync push

Update a group

1. Directly edit the group file in the config folder
   fields that support editing: (edit other fields will not work)

groupName
publicLinkEnabled
publicLinkLimit
publicLinkLimitEnabled

2. Run command asc testflight betagroup sync push

[adamjcampbell]

Some preliminary suggestions and thoughts
Looking pretty good! This may go through some designing though

[adamjcampbell]

Same goes for BetaGroup

[DechengMa]

An optional id is for creating a beta group. When creating a new group we don't have the id yet. we can basically create a file with just minimal information (eg. group name, link enabled, etc) and push back

[adamjcampbell]

This is where things can get interesting.. Having variables that will populated when pulled from disk but not populated when retrieved from the network

[adamjcampbell]

We could potentially only use the id for matching.. do we ever foresee having duplicates?

Did you have to override the default implementations because of the testers file path? There may also be a different solution here 🤔

[DechengMa]

Very true. for now, this is only for comparing the BetaGroup object difference, not for testers. when doing something like Set(localGroups).subtracting(serverGroups) I can get the difference and update the server by local

Changes were made upon request

[orj]

@DechengMa sorry I've not reviewed this. I'd like to try building a workflow based on this work to test it out.

[DechengMa]

@DechengMa sorry I've not reviewed this. I'd like to try building a workflow based on this work to test it out.

Sure no problem. Please PM directly if there's anything that I can do to help. And I'll be around for fixing any bugs / unexpected behaviours in the first place.

[orj]

I think we should be normalising the filename a bit better here. groupName could be an unsafe filename. We should turn all non alpha numeric characters into underscores.

extension String {
  func filenameSafe() -> String {
    let unsafeFilenameCharacters = CharacterSet(charactersIn: " *?:/\\.")
    return str.components(separatedBy: unsafeFilenameCharacters).joined(separator: "_")
  }
}

I'm working with an app that has a beta group named "a/h_Security" so this code creates a subdirectory named "bundleId_a" with a file in it called "h_Security.yml"

[orj]

For an account that has a lot of groups it would be better to nest them in subdirectories. The app.bundleId could be a subdirectory rather than a prefix.

Also, surely the app.bundleId will be non-nil? When will it ever be nil?

[orj]

Actually thinking about he normalised/safe filename some more I think when group names are translated to file/path names they should be really cleaned up:

Eg: A group name like d_App Team (Learn & Adopt) should be translated to d-app-team-learn-adopt. The problem with that however is that removing characters might mean there could be clashes. We might have to come up with some resolution strategy in that case.

[orj]

What I'm trying to suggest here is that the filenames should be names that a developer might choose if they were authoring them themselves.

[orj]

This is good work @DechengMa but I think we need to refine it a bit.

The current pulled structure is very flat and includes redundant data. I think we should change the structure so it is like this:

• config/betagroups/
  • com.example.appid/
    • safe-group-name/
      • betagroup.yml
      • betatesters.csv

[orj]

Something else I'd like us to clean up here is the duplication of information. When we pull down the details of the beta group the app element is repeated in each betagroup file. This isn't ideal. It would be better if it was not repeated.

[DechengMa]

a new redesigned sync command will be implemented in #203