Automatically publish releases on CI #1510
Conversation
| tags: | ||
| - '[0-9]+.[0-9]+*' |
There was a problem hiding this comment.
Our tags have three numbers, not two. Also the dot needs escaped since it matches any character, not just a dot. However, I would recommend just removing this completely and instead just use a full wildcard ** like we do in other projects: https://github.com/cashapp/molecule/blob/trunk/.github/workflows/release.yaml#L3-L6
There was a problem hiding this comment.
This is based on the discussion @swankjesse & I had - we wanted to have basic tag format validation, that would accept valid versions, even ones we don't normally use (e.g., "1.0-SQUARE"), and reject obviously incorrect ones (e.g., "hello").
| @@ -1,7 +1,6 @@ | |||
| org.gradle.jvmargs='-Dfile.encoding=UTF-8' | |||
|
|
|||
| GROUP=com.squareup | |||
| VERSION_NAME=1.14.0-SNAPSHOT | |||
There was a problem hiding this comment.
Doesn't this break the ability to do Maven local deploys for testing?
There was a problem hiding this comment.
It does, yep. This likely breaks more things, and will generally be non-ergonomic for local development.
| - name: Set release version | ||
| if: startsWith(github.ref, 'refs/tags/') | ||
| run: echo "VERSION_NAME=${GITHUB_REF#refs/tags/}" >> gradle.properties |
There was a problem hiding this comment.
We had a setup like this in RxAndroid that was mostly forced on us from the RxJava Travis CI infrastructure. Personally, I was glad to see it go away when we moved to GitHub Actions and I greatly prefer the explicit version. In other projects I'm editing the README and CHANGELOG when I release to indicate the next version so I'm not sure whether there's a ton of value in automating only one location.
If you want to go down the automating route I would like to see a workflow that's manually dispatched where the version is in the input. It would automatically update the README, migrate the CHANGELOG entries from an "Unreleased" section to a versioned section, and do the gradle.properties update/tag/update dance.
There was a problem hiding this comment.
That makes sense.
Taking a step back, the main quality of life improvements I'd love to get from this change is not having to build the project locally (and risking using a wrong JDK or incorrect environment setup in general) for release, and not having to host signing keys on my machine - these can be achieved even without these extra workflow improvements. Given that this setup likely needs much more work to be pleasant to use, I feel like sticking with the basic requirements, and leaving the rest for later. Let me know if you have thoughts!
There was a problem hiding this comment.
I don’t like having to do 2 commits per release. Changing the property for the current release and again for the next snapshot is a bit clumsy.
I also don’t like how the tag and the property duplicate information.
I’d like to discuss our options on a VC, maybe next week?
No description provided.