Promote specific version codes

[dan-lexicon]

Thanks for creating this great plugin!

Problem description

As I understand, the promoteArtifact tasks will lookup all the releases in the fromTrack and pick the one with the highest version code to promote to the promoteTrack, and include any version codes in retain.artifacts in the lookup.

This always assumes that the latest release in the fromTrack is the one that should be promoted.

It should be possible to promote other releases in the fromTrack, assuming the version code of the release is greater than any in the promoteTrack.

Potential solutions/workarounds

I'd like to request the ability to configure a specific version code for use by the promoteArtifact task.

If configured, the promotion task should find the release in the fromTrack with the configured version code(s).

The configuration could be declared as a specific version code list:

play {
    fromTrackVersions.add(123L) 
    // No configuration would default to the highest version code in fromTrack 
}

Or configured to either check the android plugin's version code, or latest from the track:

android {
    defaultConfig {
        versionCode = 123
    }
}

play {
    promotionMode.set(PromotionMode.CURRENT_VERSION_CODE)

    // Alternatively:
    // promotionMode.set(PromotionMode.LATEST)

    // No configuration would default to PromotionMode.LATEST
}

Either option should also be configurable from the CLI.

Additional context

This is to support our use case where we have frequent uploads/promotions to testing tracks. We want to select specific releases to promote to production that have passed the checks of extra scrutiny. These checks can be manual and take more time than the frequency of upload to testing tracks.

I'm also happy to attempt a contribution if you agree with this approach

[SUPERCILEX]

I'm not sure I understand the possible scenario... would you mind sharing a concrete example when you'd have multiple releases in a single track with sample version codes, tracks, and release statuses (draft, in progress, completed)?

[dan-lexicon]

Yeah examples always help!

So we're using trunk based development, with the core idea that you should build a binary only once, and promote it when confidence is built. Discard any binary that fails a check.

To start, if all of our unit/UI tests pass CI, we'll upload to internal or closed testing tracks to distribute to our team.

This will happen on every merge to main/trunk. Version code (v123) coupled to build number (b123). Will use Alpha as the testing track in this example. For this scenario, all release statuses will be immediately completed, and not use user fractions.

A build could pass and it will be uploaded to Alpha:

[CI | b1] => [Alpha | v1 | Completed]

Since it's our only build, let's ship it:

[CI | b1] => [Alpha | v1 | Completed] => [Prod | v1 | Completed]

Running another build will upload to Alpha again. v1 will be replaced:

          => [Alpha | v1 | Replaced ] => [Prod | v1 | Completed]
[CI | b2] => [Alpha | v2 | Completed]

While we're doing additional testing/verification/sign-off on v2, we might have more builds running on trunk (v3):

          => [Alpha | v1 | Replaced ] => [Prod | v1 | Completed]
          => [Alpha | v2 | Replaced ]
[CI | b3] => [Alpha | v3 | Completed]

Now v2 has been signed off and we're ready to promote it to prod. Right now the GPP plugin will pick v3, but I want v2.

          => [Alpha | v1 | Replaced ] => [Prod | v1 | Replaced ]
          => [Alpha | v2 | Replaced ] => [Prod | v2 | Completed]
          => [Alpha | v3 | Completed]

If I use retain.artifacts.add(2), the promotion will attempt to promote both v2 and v3, but fails because v2 can't be active at the same time as v3 in the same track.

But I don't think retain artifacts is the right mechanism/semantic for what I want, so the suggestion is for a specific version code on the promote task.

Hopefully this all makes sense!

[SUPERCILEX]

Ohhhhh, I see, so you want to be able to promote artifacts that aren't in a track. I'd never thought of that one before.

Would it maybe make sense to promote artifacts that are undergoing verification to a staging track of sorts? The Play Console lets you create arbitrary tracks, so maybe you could create a staging or in-verification track where you move those artifacts. Then when you want to go to prod, you promote from that track. Or is the issue that you don't know in advance which artifact will be the one you end up promoting to prod?

[dan-lexicon]

Or is the issue that you don't know in advance which artifact will be the one you end up promoting to prod?

This is true fairly often, yes.

We only want to have one manual step in our delivery pipeline; the go to prod button. Since every build is a potential release candidate, having a separate staging track would leave us with the same problem since we'd just have every build end up there as well

[SUPERCILEX]

Gotya, that all makes sense. Thanks!

[dvdciri]

Really looking forward to this one as well! 👍🏼