feat: Refactor handling of project version numbers and tags#1147
Merged
isabelle-dr merged 9 commits intoMobilityData:masterfrom May 24, 2022
Merged
feat: Refactor handling of project version numbers and tags#1147isabelle-dr merged 9 commits intoMobilityData:masterfrom
isabelle-dr merged 9 commits intoMobilityData:masterfrom
Conversation
…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.
Collaborator
Author
|
(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).
We can't update this code until the PR actually goes in on the master branch.
Contributor
maximearmstrong
left a comment
maximearmstrong
left a comment
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.
Member
|
@bdferris-v2 The branch rules require that the main branch be merged into the PR, if you could do that. |
Collaborator
Author
|
Hopefully should be merged at this point. |
Contributor
|
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.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.