Remove version from github release artifact name

[zendern]

• What are you trying to do?
  Make it even easier to install nancy and stay up to date.

• What feature or behavior is this required for?
  If i wanted to download nancy as part of a build and not have to build from source it should be easy to do and easy to keep up to date.

Github has an auto redirect if you use the following url that will take you to the latest release.
https://github.com/sonatype-nexus-community/nancy/releases/download/latest/nancy-darwin.amd64-v0.0.31

But it doesn't really do much good for us since we include the version number in the artifact name.

Proposal is to switch it to this. That way we can suggest that people just curl/wget this url and it will give the the latest and greatest nancy binary available.
https://github.com/sonatype-nexus-community/nancy/releases/download/latest/nancy-darwin.amd64

• How could we solve this issue? (Not knowing is okay!)
  Remove the version number from the release artifact when releasing via travis

cc @bhamail / @DarthHater

[DarthHater]

I'm really on the fence about this, mainly because I think of artifacts as immutable, and namespacing them with version accomplishes that to some degree. I wish GitHub had functionality that had a "latest" to download from.

[zendern]

Although they are namespaced once you create the release anyways. You can see v0.0.32 is already in the url and github gives you the "latest" download shortcut but just not at the artifact level.

https://github.com/sonatype-nexus-community/nancy/releases/download/v0.0.32/nancy-darwin.amd64-v0.0.32

So the namespacing would still be a thing after the change
https://github.com/sonatype-nexus-community/nancy/releases/download/v0.0.32/nancy-darwin.amd64

And now allow for this
https://github.com/sonatype-nexus-community/nancy/releases/download/latest/nancy-darwin.amd64

[bhamail]

I think I just stumbled into another use case for which a "latest" artifact is a perfect solution. Namely: A CircleCI Orb that by default will always use the most recent nancy release to perform a scan.

I'm going to look into adding a new "latest" release artifact.

[bhamail]

Well pooh! I spoke too soon. The path to the "latest" release on GitHub will always include the version as part of the path (version is embedded in the path as well as the filename). So....I'm looking into a solution that uses a GitHub API to get the latest version, and with that, build a path/filename URL with the real "latest" version embedded.

[bhamail]

OK, I think I have a path forward. Here's what I did in the CircleCI Orb to get a "default" of "latest" working:
sonatype-nexus-community/circleci-nancy-orb@4862e8f

Also, learned the CircleCI Orb can be specified with a "semantic version", like @0 (e.g. sonatype-nexus-community/circleci-nancy-orb@0) which will ensure an updated Orb is used too.

Will try to take a look at the github action next week (unless someone beats me to it).

[zendern]

@bhamail did you try this then?? I see your comment about Version in the path but I think they handle it if the file name has no version with this.

https://docs.github.com/en/github/administering-a-repository/linking-to-releases

[cah-nathan-zender]

So something like this @bhamail

https://github.com/sonatype-nexus-community/nancy/releases/latest/download/nancy-v1.0.15-darwin-amd64

and if you revert your revert it should just work :) b/c then there would be no version number in the artifact. This is what i wanted :)

https://github.com/sonatype-nexus-community/nancy/releases/latest/download/nancy-darwin-amd64

[bhamail]

I've talked myself out of the "versionless path/filename" approach.

• I have bad memories of unversioned .jars and the general sense of wonder about what version of stuff was actually running.
• Once I have a fully versioned path/filename determined, it is easy to "log" what version we are fetching/using

I have a PR in flight that uses fully versioned path for getting the "latest" for the github action (already done for the CircleCI Orb).

[bhamail]

I think I have the tooling sorted (see prior comments), and working. Closing this now, but please holler if use cases arise where the github api will not suffice.