Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Bundle IDs and Capabilities endpoints #57

Merged

Conversation

BalestraPatrick
Copy link
Collaborator

This PR implements all the Bundle ID Capabilities and Bundle IDs endpoints.

Sorry for the big PR, but a lot of models are shared between the two web services. I have the Profiles and Devices endpoints ready too, but I was able to split those into a different future PR to make it easier to review.

Feedback is welcome on the API design and everything. I did some smoke tests for all the endpoints and they work just fine.

public struct BundleId: Codable {

/// The resource's attributes.
public let attributes: BundleId.Attributes?
Copy link

@ghost ghost Dec 29, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ An ‘instance_property’ should not be placed amongst the type content(s) ‘subtype’.
type_contents_order BundleId.swift:14

public let attributes: BundleId.Attributes?

/// The opaque resource ID that uniquely identifies the resource.
public let `id`: String
Copy link

@ghost ghost Dec 29, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ An ‘instance_property’ should not be placed amongst the type content(s) ‘subtype’.
type_contents_order BundleId.swift:17

public let `id`: String

/// Navigational links to related data and included resource types and IDs.
public let relationships: BundleId.Relationships?
Copy link

@ghost ghost Dec 29, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ An ‘instance_property’ should not be placed amongst the type content(s) ‘subtype’.
type_contents_order BundleId.swift:20

public let relationships: BundleId.Relationships?

/// The resource type.Value: bundleIds
public let type: String = "bundleIds"
Copy link

@ghost ghost Dec 29, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ An ‘instance_property’ should not be placed amongst the type content(s) ‘subtype’.
type_contents_order BundleId.swift:23

public let type: String = "bundleIds"

/// Navigational links that include the self-link.
public let links: ResourceLinks<BundleIdResponse>
Copy link

@ghost ghost Dec 29, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ An ‘instance_property’ should not be placed amongst the type content(s) ‘subtype’.
type_contents_order BundleId.swift:26

@ghost
Copy link

ghost commented Dec 29, 2019

1 Warning
⚠️ Big PR
1 Message
📖 View more details on Bitrise

Generated by 🚫 Danger

Sources/Models/BundleId.swift Outdated Show resolved Hide resolved
import Foundation

/// A response containing a list of related resource IDs.
public struct BundleIdCapabilitiesResponse: Codable {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Conforming to Decodable only should suffice here, can this be adjusted? The same should apply to the other response types and most of the nested types.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Every other model conforms to Codable. Searching for types conforming to Codable results in 418 results, searching for Decodable yields only 15 results (mostly related to this PR actually). Should we for consistency keep everything conform to Codable? I change change all instances in this PR to conform to Codable instead of just Decodable like the rest of the codebase.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for looking into this @BalestraPatrick! I'm happy to stick to the conventions already in use in the project.

import Foundation

/// A request containing a single resource.
public struct BundleIdCapabilityCreateRequest: Codable {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, if should be enough conforming to Encodable here (and other request types), as well as most nested types.

Sources/Models/BundleIdResponse.swift Outdated Show resolved Hide resolved
Sources/Models/CapabilityOption.swift Show resolved Hide resolved
@AvdLee
Copy link
Owner

AvdLee commented Dec 30, 2019

If you don't get the same warnings locally as here in CI, you might want to update the WeTransfer-iOS-CI submodule. This makes sure that SwiftLint is run locally as well and triggers the same warnings locally. I'll see if I can make this process easier to understand.

@BalestraPatrick
Copy link
Collaborator Author

@ruipfcosta @AvdLee This is ready for another round of review whenever you have time 👍

Copy link
Owner

@AvdLee AvdLee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Amazing job, Patrick! Great job on keeping the code consistent with the rest of the project. I've got a small suggestion and I'm interested to hear your thoughts on it!

- Add support for all [Bundle ID](https://developer.apple.com/documentation/appstoreconnectapi/bundle_ids) endpoints. (@ruipfcosta, @BalestraPatrick)
- Add support for all [Bundle ID Capabilities](https://developer.apple.com/documentation/appstoreconnectapi/bundle_id_capabilities) endpoints. (@BalestraPatrick)
- Updated CI to make sure PR requests are reviewed using Danger. (@AvdLee)
- Removed custom Result type. (@ruipfcosta)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work on the details here!

path: "bundleIdCapabilities",
method: .post,
parameters: nil,
body: try? JSONEncoder().encode(request))
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If encoding here fails, it would fail silently. This might make it harder to debug eventually if it's causing the request to fail as well. What do you think about making the enableCapability method throwing?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took inspiration from all other methods that don't propagate the failure right now. There are other 36 instances of try? JSONEncoder().encode(request) in the project, so not sure it's worth changing these new methods to a new convention.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, you're right! Lets keep it like this for now.

@AvdLee AvdLee merged commit f2a3a29 into AvdLee:master Jan 6, 2020
@BalestraPatrick BalestraPatrick deleted the bundle-ids-and-capabilities-endpoints branch January 6, 2020 15:59
@SwiftLeeBot
Copy link
Collaborator

Congratulations! 🎉 This was released as part of Release 1.0.0 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants