Vampire
04/19/2023, 12:54 PM"null"
and ""
were serialized wrongly as null
.
We have the same problem with Strings that look like other scalars like ints, floats, and booleans. A String with value "4.0"
for example is serialized as 4.0
which then is interpreted as the float 4.0
and thus given as 4
where used, for example in ${{ matrix.variant }}
.
Should we finally just single-quote all single-line Strings, or introduce some more parsing to determine whether it needs quotes or not?Piotr Krzemiński
04/19/2023, 2:02 PMVampire
04/19/2023, 2:05 PMif (this is String) {
if (lines().size > 1) {
ScalarStyle.LITERAL
} else if (isEmpty() || (this == "null")) {
ScalarStyle.SINGLE_QUOTED
} else {
ScalarStyle.PLAIN
}
}
which strives to produce better readable YAML output by not quoting all single-line strings. But for the price of issues like these two.Piotr Krzemiński
04/19/2023, 2:06 PMVampire
04/19/2023, 2:43 PMPiotr Krzemiński
04/19/2023, 3:24 PMVampire
04/19/2023, 3:25 PMBigDecimal
anyway. :-DPiotr Krzemiński
04/19/2023, 3:29 PMVampire
04/19/2023, 3:30 PMPiotr Krzemiński
04/19/2023, 4:45 PMVampire
04/19/2023, 4:55 PMmatrix.groovy
where the build script reads them and also the workflow kts files read them from.2.5
, 3.0
, and 4.0
to the workflow YAML.
But before they were Strings in quotes, so for example produced the job Verify Branches and PRs / Build and Verify (ubuntu-latest, 3.0, 8) (pull_request)
and giving 3.0
as project property to the Gradle build.
Now with the lib it produces the job Verify Branches and PRs / Build and Verify (ubuntu-latest, 3, 8) (pull_request)
and gives 3
as project property to the Gradle build.2.5
, 3.0
, and 4.0
, but after the YAML is parsed and you use the value using ${{ matrix.variant }}
it was converted to a number and is only given as 3
.FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':library:publishMavenJavaPublicationToMavenLocal'.
> Failed to publish publication 'mavenJava' to repository 'mavenLocal'
> Invalid publication 'mavenJava': artifact file does not exist: '/home/jitpack/build/library/build/libs/library-0.41.0-sources.jar.asc'
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
* Get more help at <https://help.gradle.org>
BUILD FAILED in 2m 19s
24 actionable tasks: 17 executed, 7 up-to-date
Publishing build scan...
<https://gradle.com/s/ri5jagwk6cixw>
Build tool exit code: 0
Looking for artifacts...
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Dhttps.protocols=TLSv1.2
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Dhttps.protocols=TLSv1.2
Looking for pom.xml in build directory and ~/.m2
Found artifact: io.github.typesafegithub:github-workflows-kt:0.41.0
2023-04-19T17:06:31.992197934Z
Exit code: 0
⚠️ ERROR: No build artifacts found
Expected artifacts in: $HOME/.m2/repository/io/github/typesafegithub/github-workflows-kt/0.41.0
mavenLocal()
, you require signing even though it is not a release and thus it fails.main
it behaves as expected again.Piotr Krzemiński
04/19/2023, 6:10 PMVampire
04/19/2023, 7:14 PMPiotr Krzemiński
04/19/2023, 7:43 PMVampire
04/19/2023, 7:54 PMThanks for the idea! I'll definitely consider itFor the meantime: https://github.com/typesafegithub/github-workflows-kt/pull/775
BTW, Jitpack building worked some time ago, I wonder why it brokeGradle update from 7.4.1 to 8.1 I guess
Piotr Krzemiński
04/19/2023, 7:59 PMVampire
04/19/2023, 8:00 PMPiotr Krzemiński
04/19/2023, 8:05 PMVampire
04/19/2023, 8:06 PMPiotr Krzemiński
04/19/2023, 8:08 PMVampire
04/19/2023, 8:08 PMPiotr Krzemiński
04/20/2023, 6:46 AMBtw. when anyway reworking the publishing, you should consider applying the https://github.com/gradle-nexus/publish-plugin, especially when using Sonatype to publish to Maven Central it is quite flaky without it and if wanted it can also help completely automating the release without needing to finish it on the Nexus UI.we already use it https://github.com/typesafegithub/github-workflows-kt/blob/25657f3272f0c74ffb40364af07957f0d50ee6ad/build.gradle.kts#L5
Vampire
04/20/2023, 7:03 AMdsl-publishing
, didn't see it there and seen manual repository configuring.
Controlling the version manually is absolutely in my favor. Or at least just doing it on explicit task execution and updating and committing a file. I hate it if versions are calculated from VCS history. This makes builds less reproducible, they don't work from an exported sources archive, they don't even work in a Git worktree.
I usually update the patch version directly after release, also adding -SNAPSHOT
, and bump the minor or major version with the commit that requires this bump. This then builds the proper snapshot builds for the proper next version. And before release I remove the snapshot suffix. The work around the release I usually do using the gradle-release plugin.
You currently always build the last released version, even though there were additional changes. This can be quite confusing, especially when using maven local.Piotr Krzemiński
04/20/2023, 7:06 AMThe work around the release I usually do using the gradle-release plugin.I’m keen to try out this plugin one day!
You currently always build the last released version, even though there were additional changes. This can be quite confusing, especially when using maven local.I don’t understand where’s the problem now. If one wants to use maven local, they by default work on the latest commit, and if desired, can check out a tag for a given release.
Vampire
04/20/2023, 7:40 AM0.41.0
. I deploy it to Maven local to test some changes. So I test it in a workflow still having 0.41.0
declared while it actually is 0.42.0-SNAPSHOT
. I'm fine with my changes, create a PR and you merge it, next day you create a new release so I update my version and be good. Two weeks later I open another project that still uses 0.41.0
. I try to build the workflows and it fails (due to the changes in Maven local I forgot by then). Now I open a bug entry for you, or that project, or adapt to the changes according to IDE and push and thereby breaking it for the others, .......Piotr Krzemiński
04/20/2023, 7:45 AMx.y.z-SNAPSHOT
) instead of using x.y.z
every time that looks like a released version, right?Vampire
04/20/2023, 8:07 AM!:
the major version (or minor while at 0.
) needs to be higher than in the last tag, if no feat
, then the patch version needs to be higher, if also feat
then the minor version needs to be higher.Piotr Krzemiński
04/20/2023, 8:19 AMincrease the version in time when the changes require the change.do you mean bumping the version in the very same commit/PR that makes a certain change? so a functional change + major/minor/patch version bump?
Vampire
04/20/2023, 9:03 AMPiotr Krzemiński
04/20/2023, 9:24 AMVampire
04/20/2023, 9:41 AMPiotr Krzemiński
04/20/2023, 9:44 AMNot “each” commit is polluted, only the first feature-commit and the first breaking-commit after a release.ok, got it now! so it also assumes that each version bump besides the “patch” part results in a release, right?
Vampire
04/20/2023, 10:21 AMPiotr Krzemiński
04/20/2023, 10:32 AM-SNAPSHOT
to the current version. Will take care of it “later” 🙂 (after work)Vampire
04/20/2023, 11:19 AMso you do “Set version to 1.0.1-SNAPSHOT” as a minimal version bump after v1.0.0 which says “there’s going to be at least a patch-like change, and if something bigger, let’s bump more significant version numbers”Exactly
Will take care of it “later” 🙂 (after work)👌 And then you can also easily publish to Sonatype snapshot repository on each push to
main
. 🙂
are you aware of any tool (for git/GitHub) that would help enforce such versioning based on conventional commits?
this approach is very algorithmic, provided that one correctly uses conventional commitsYes, that's what I mentioned, that you should be able to verify it by the commit messages, but no I'm not aware of any such tool.
Piotr Krzemiński
04/20/2023, 12:02 PMVampire
04/20/2023, 1:24 PMPiotr Krzemiński
04/20/2023, 1:24 PMVampire
04/20/2023, 2:32 PMPiotr Krzemiński
04/26/2023, 9:47 AMVampire
04/26/2023, 10:39 PMSNAPSHOT
version so that you can publish to maven local without hassle
• Shouldn't it already be at 0.42.0-SNAPSHOT
as you already introduced 5 new feat
commits?
• The releasing instructions talk about a develop
branch, but there is no such branch. Or do you intend to change your process to Git Flow?
• Please add to the instructions to use annotated tags and probably also update the existing tags to be annotated ones. Lightweight tags are for short-lived temporary tags, annotated tags are for persistent things like version tags. There are for example quite some commands or tools which consider annotated tags but ignore lightweight tags unless told otherwise if possible. For example try to do git describe
.Piotr Krzemiński
04/27/2023, 5:09 AMVampire
04/28/2023, 10:16 AMPiotr Krzemiński
04/28/2023, 10:16 AMVampire
04/28/2023, 10:18 AMPiotr Krzemiński
04/28/2023, 10:19 AMVampire
04/28/2023, 10:19 AMPiotr Krzemiński
04/28/2023, 10:25 AMVampire
04/28/2023, 10:27 AM-SNAPSHOT
, creates tag on it, makes another commit that increases the patch-version and re-adds -SNAPSHOT
.