feat: Refactor handling of project version numbers and tags #1147
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ject.
Currently, project version info is passed in via a `versionTag` env variable,
which is only specified in the Github workflow environment. Consequently,
`project.version` ends up being `null` when run locally. This causes
weirdness for tools that expect a valid version number.
This change switches the project to use the axion-release plugin, which
determines the project version by looking at the git repo's tags.
Along with that switch, I've moved the project group and version
specification into the root build.gradle allprojects {} such that
these values do not need to be specified in each sub-poject.
I also did some related clean-up for our jitpack configuration (and
Maven repository modules, should we every decide to publish them).
I believe our current jitpack config doesn't actually work correctly
because we only publish artifacts from the main package, but not core.
You can see this in practice when looking at:
https://jitpack.io/com/github/MobilityData/gtfs-validator/3.0.1/gtfs-validator-3.0.1.pom
Notice how it has a dependency on the `core` module but we don't
actually publish it anywhere. If you actually attempt to use our
project as a jitpack dependency, it will fail.
The change was to also publish the core module and to specify more
natural artifact names.
|
(This isn't ready for review yet. I just wanted to see what would happen with all the workflow tasks.) |
longer needed now that project version is determined within Gradle directly. Also fixup references to shadow jars, since they no longer include the versionTag in the filename (also _cli => -cli).
maximearmstrong
added this to In Review
in The Tech Dashboard (archived)
via automation
We can't update this code until the PR actually goes in on the master branch.
There was a problem hiding this comment.
Thanks @bdferris-v2, this looks good! Some thoughts in-line.
I also cleaned up some other variables from the docker config that don't seem to be used.
barbeau
reviewed
May 23, 2022
…previous commit.
|
@bdferris-v2 The branch rules require that the main branch be merged into the PR, if you could do that. |
|
Hopefully should be merged at this point. |
|
I forgot to add my review before merging: I approve this PR, thanks! |
bdferris-v2
added a commit
to bdferris-v2/gtfs-validator
that referenced
this pull request
May 25, 2022
…now that PR MobilityData#1147 has been committed.
3 tasks
maximearmstrong
pushed a commit
that referenced
this pull request
May 25, 2022
* Per issue #1139, refactor how versions are handled in project. Currently, project version info is passed in via a `versionTag` env variable, which is only specified in the Github workflow environment. Consequently, `project.version` ends up being `null` when run locally. This causes weirdness for tools that expect a valid version number. This change switches the project to use the axion-release plugin, which determines the project version by looking at the git repo's tags. Along with that switch, I've moved the project group and version specification into the root build.gradle allprojects {} such that these values do not need to be specified in each sub-poject. I also did some related clean-up for our jitpack configuration (and Maven repository modules, should we every decide to publish them). I believe our current jitpack config doesn't actually work correctly because we only publish artifacts from the main package, but not core. You can see this in practice when looking at: https://jitpack.io/com/github/MobilityData/gtfs-validator/3.0.1/gtfs-validator-3.0.1.pom Notice how it has a dependency on the `core` module but we don't actually publish it anywhere. If you actually attempt to use our project as a jitpack dependency, it will fail. The change was to also publish the core module and to specify more natural artifact names. * Remove references to versionTag env variable in workflows. It is no longer needed now that project version is determined within Gradle directly. Also fixup references to shadow jars, since they no longer include the versionTag in the filename (also _cli => -cli). * Restore versionTag behavior for master branch. We can't update this code until the PR actually goes in on the master branch. * Fix typo in yml. * Download artifacts to separate directories to avoid eventual name conflicts. * Remove all references to versionTag from docker.yml I also cleaned up some other variables from the docker config that don't seem to be used. * Remove all references to versionTag from test_pack_doc.yml * Add back `tags` output variable, which was improperly removed in the previous commit. * Resolve TODO to correctly handle -cli.jar reference on master branch now that PR #1147 has been committed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Per issue #1139, refactor how versions are handled in project.
Currently, project version info is passed in via a
versionTagenv variable, which is only specified in the Github workflow environment. Consequently,project.versionends up beingnullwhen run locally. This causes weirdness for tools that expect a valid version number.This change switches the project to use the axion-release plugin, which determines the project version by looking at the git repo's tags.
Along with that switch, I've moved the project group and version specification into the root build.gradle allprojects {} such that these values do not need to be specified in each sub-poject.
I also did some related clean-up for our jitpack configuration (and Maven repository modules, should we every decide to publish them). I believe our current jitpack config doesn't actually work correctly because we only publish artifacts from the main package, but not core.
You can see this in practice when looking at:
https://jitpack.io/com/github/MobilityData/gtfs-validator/3.0.1/gtfs-validator-3.0.1.pom
Notice how it has a dependency on the
coremodule but we don't actually publish it anywhere. If you actually attempt to use our project as a jitpack dependency, it will fail.The change was to also publish the core module and to specify more natural artifact names.