fix: Update acceptance_test.yml to reflect new -cli.jar naming. #1168
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.
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.
I also cleaned up some other variables from the docker config that don't seem to be used.
…previous commit.
…now that PR MobilityData#1147 has been committed.
4 tasks
|
Oh, just realized this is still marked as "draft". Was it ready for review? |
|
@barbeau I was just waiting to see if the Acceptance Test actually ran successfully before flipping over for review. It looks like it's working! @maximearmstrong or @isabelle-dr any chance you could review? I think Acceptance Test will continue to fail until we get this in. |
maximearmstrong
approved these changes
May 25, 2022
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.
Summary:
As part of issue #1139, PR #1147 changed how shadow jar artifacts are named. We updated that naming in all GitHub workflows except for one place in
acceptance_test.ymlwhere it continued to reference the jar produced on themasterbranch with the old naming scheme. Now that PR #1147 is in on themasterbranch, we can resolve the TODO there to reference the new jar naming scheme.Closes #1139.
gradle testto make sure you didn't break anything