luke
luke
Question for @dandelany, should this plugin version track the Aerie version?
@dandelany another thought, we might need to expose `${{ github.actor }}` and `${{ secrets.GITHUB_TOKEN }}` as environment variables (for gradle to use) in our e2e tests workflows if these aren't...
Hmm good question @JoelCourtney . We'd want to make sure end users can define which version of Aerie deps they want to grab. One option would be pinning this Gradle...
I've taken a slightly different approach implementing this @JoelCourtney @mattdailis. The procedural plugin's version won't directly track Aerie version, since I wasn't able to propagate specific dependency versions to plugin...
They actually are published already @JoelCourtney! https://github.com/NASA-AMMOS/aerie/packages/2282306 I sort of accidentally did this, I didn't realize my test API token had write permissions to the aerie packages 🫣. As stated...
Placing this on hold for now while we revisit the `GITHUB_TOKEN` requirement; ideally we could consume this plugin locally instead of requiring a build to already be published, but gradle...
This would be incredible