touchlab / kmmbridge Goto Github PK

with a version prefix config. Made available to the file uploader. Given to the dependency manager on publish

Specifically "Version numbering" and below needs a refresh. Also, some fo this is really covered in CI docs, so we may want to review how all of that ties together.

We should make sure that any samples and config for Cocoapods works for both ssh and https. Using one or the other is sometimes a team choice and sometimes personal preference, but we can expect different teams to use both.

Add a GH release on deploy

This should include:

• How to add a published SPM project repo from Github
• How to configure the Package.swift file for local dev
• How to drag the local dev folder into Xcode
• How to run gradle locally to rebuild the framework

Ideally we could mandate that version prefixes are compatible with semantic versioning, or at least whatever is compatible with SPM and cocoapods. It may be sufficient to have a warning about it.

The FaktoryExtension/KMMBridgeExtension has helper methods specific to certain types of artifact and dependency managers. Since these will probably grow and be added to by others, it would make sense to move this config into Kotlin extension methods that live with the implementations.

So, for example, this method is directly in the Gradle extension class:

interface FaktoryExtension
    //etc
    fun s3Public(
        region: String,
        bucket: String,
        accessKeyId: String,
        secretAccessKey: String,
        makeArtifactsPublic: Boolean,
        altBaseUrl: String?
    ) {
        artifactManager.set(
            AwsS3PublicArtifactManager(
                region,
                bucket,
                accessKeyId,
                secretAccessKey,
                makeArtifactsPublic,
                altBaseUrl,
                this
            )
        )
    }
    //etc
}

It would make more sense to do this in the AwsS3PublicArtifactManager file:

fun FaktoryExtension.s3Public(
    region: String,
    bucket: String,
    accessKeyId: String,
    secretAccessKey: String,
    makeArtifactsPublic: Boolean,
    altBaseUrl: String?
) {
    artifactManager.set(
        AwsS3PublicArtifactManager(
            region,
            bucket,
            accessKeyId,
            secretAccessKey,
            makeArtifactsPublic,
            altBaseUrl,
            this
        )
    )
}

class AwsS3PublicArtifactManager(
    private val s3Region: String,
    private val s3Bucket: String,
//etc

This will allow us to have separate extension modules that don't need to be included in the main module, or possibly even private extensions.

• Add OSS License!!!
• Update plugin version in readme
• Link to KMM Bridge blog post in readme (does not exist yet)
• Link to Repo in blog posts
• Scan github issues and git history for sensitive info
• Make Repos public
  • KMMBridge
  • Samples
  • Podspec
• Double check that JB's post links correctly
  • Also confirm all the other links are right such as touchlabHQ and touchlab.co
• Publish a version of the KMM Bridge Actions workflow (not main)
• Change samples and docs to use version
• Review samples
• Update docs
• Update versions (plugin, etc)

Add to this list as we're prepping release...

Move relevent info from GitHubCI.md to COCOAPODS_GITHUB_PODSPEC.md. It should cover:

• Creating a repo. It is critical that there's at least one commit, so add a readme (it doesn't work without a commit)
• Adding/creating deploy keys (remove Gitlab reference. We'll need to look into that later)
• Adding the spec repo to your kotlin config

Please include screenshots for the web UI for the deploy keys sections, and what the spec repo should look like after a release has been successfully published.

On adding to CI, I'd just link out to the default flow file section that does this rather than trying to explain (Link: https://github.com/touchlab/KMMBridgeGithubWorkflow/blob/f6075b60151caf15b8759c811b0d2458fbdd08a7/.github/workflows/faktorybuild.yml#L21)

Doc explaining a simple working setup using github files.

(what to test?)

Right now we depend on the version prefix for github artifact names, but if we make the version prefix optional, we should look at just defaulting to a name or requiring one.

Just a simple GA workflow to run tests

We can leave this relatively sparse. Just explain what the methods do and point to the public examples. Actually getting access to private artifacts can be rather complicated, so whoever is attempting to do this will have a lot to figure out on their own. Quick starter docs would be useful, though.

Can we use some Gradle standard publishing mechanism to push zip artifacts? This might let us push to github artifacts, Artifactory, or any of several other options.

Specifically, we'll need a way to publish files, then get a reference to the published zip file itself. A direct URL that we can put in file configs.

Note: We may not be able to access all of them from Xcode, depending on how auth is handled. We'll likely need to be able to access them through ~/.netrc, which means some form of simple user/password. However, this is a separate concern we'll need to test with each publishing target. We should add specific tasks to test publishing and consuming each we'd intend to support.

Complete the iOS dev setup doc. Needs the SPM and Cocoapods sections, with solid descriptions and screenshots where applicable.

Can we push binary files to artifactory and have them be accessed with some kind of configured auth?

Can we support multiple framework modules in a single repo? What is the current state?
It will probably look different for SPM and cocoapods

Define tasks based on your findings

According to this blog post, https://medium.com/geekculture/xcode-13-3-supports-spm-binary-dependency-in-private-github-release-8d60a47d5e45, SPM should be able to support private binary release zip files as of Xcode 13.3. It also seems plausible that cocoapods could support the same. This could easily become the default for teams publishing frameworks.

Try pushing a release with this, probably using github actions first rather than trying to directly integrate with github.

The only thing we still write to the ".faktory" folder is the URL file. It should be pretty simple to pass that into the DependencyManager somehow rather than writing it to the file system and reading it again. Not entirely sure of the best way of doing that, but having it in the file system is kind of confusing.

We're managing setup of the XCFramework config. If we want to use external config, there's a lot that depends on it and we'll need to think through that and sort out dependencies and testing. That was added when the plugin was much simpler.

Currently the github releases artifact manager and the version manager are both added by the init call. Should split these to individual calls.

The SPM Dependency manager arguably does a bit too much when interacting with git. It defaults to using tags vs releases, and actually overwrites, then reverses the Package.swift file. This is all useful for a specific config, but may not be how everybody wants SPM to work specifically. Some of this may be better split out or made configurable.

We're specifically describing Github, although the intro suggests Gitlab also supports deploy keys. I think we should create sections for Github and Gitlab (we can leave Gitlab as "todo"), and add screenshots for Github.

Complete doc on dragging the local package into Xcode

Related to #25

If no file is there, leave the generated file after publishing.

We should use a random url for uploads to help make things more secure

Passing in the whole url, or presumably just the repo and not owner, will result in weird error messages.

The goal is to improve error messaging when an invalid value is passed which informs them that the input must be "Owner/Repo"

Reference: https://touchlab.slack.com/archives/C039SKWFPPW/p1664985641279769

Complete doc on "flipping the switch" for local dev

For SPM versioning to work properly, we need git tags to have the version info. Currently, only the GitReleaseVersionManager and GitTagVersionManager actually write versions. TimestampVersionManager and ManualVersionManager should also implement this.

Alternatively, we should come up with some form of writing versions that is a different abstraction.

Probably don't have a default, or if anything default to github releases

After looking at the docs and the samples, I agree that CI with Https isn't worth it, so we should just remove CocoapodsCIHttps.md and make sure nothing points to it (I don't think so). If there's anything in there of use, we can pull it out.

Tasks that generate podspec file have incorrectly configured caching. As a result, Gradle skips execution of those tasks on consecutive runs. However, these tasks must always be executed because they update the published artifact version in the podspec file.

They are probably missing something like:

outputs.upToDateWhen { false }

maven publish needs the uploadXCFramework task to depend on maven's publish task, but the ArtifactManager interface doesn't currently support that.

Proposal:
Add a fun configure(project: Project, uploadTask: Task, publishRemoteTask: Task) {} to ArtifactManager similar to DependencyManager. This gives a location where it can configure task dependencies it needs. Call that function in the same place that the DependencyManager function is called.

Add a MavenPublishArtifactManager. It can take as input the name of the publication or whatever other metadata it needs to find the correct publish task. Then it calls uploadTask.dependsOn(pubishWhateverPublicationTask) in configure() and returns the url in deployArtifact().

I have a sample of this almost working. I can get this into an example pretty quickly.

Gradle disables task caching when a doFirst/doLast are invoked with a lambda, so we should replace it with object: Action<Unit> { ... }.

Find projects to test our configuration against. Look for and report any issues

The dependency manager implementations both "publish" versions, but we push artifacts before we know if those versions are valid. The DependencyManager interface should have a "checkVersionExists" function that tells you if a version already exists, and we should call them before pushing artifacts.

We should make version manager optional, so by default, the version used is whatever would normally be used from gradle. Adding a version manager then enables automatic version incrementing.

The Github releases artifact manager currently depends on a version prefix, but this is a somewhat arbitrary decision and can be simplified.