search

samuong / alpaca

A local HTTP proxy for command-line tools. Supports PAC scripts and NTLM authentication.
Apache License 2.0
184 stars 31 forks source link

Feature/build #77

Closed rtfmoz2 closed 2 years ago

rtfmoz2 commented 2 years ago

Add build versioning for alpaca, this is a precursor for software packaging deployment

rtfmoz2 commented 2 years ago

Oh, its showing unfinished code I am currently working on, that was not my intention. Let me save my latest commits. There we go!

rtfmoz2 commented 2 years ago

They will make a lot more sense now. Why am I not using homebrew? Enterprise deployments want control over software deployment and homebrew most definitely does not fit that requirement. Hence a package is required. Since I have made one, I am trying to give back to the community by contributing to the codebase but the lack of a version is the biggest blocker to this.

Presently the build script is completely independent from main code in that they pull down the latest source directly from github, hence the build-pkg-from-src name. I have not decided the best way to use the version of the build yet and need to ask a few questions before I can.

  1. Where should I get the alpaca version from? Is it in the go files? This is why I added it as I could not find a version reference in the source code so added it independently. (I'm not a GO developer but I can read code ok)
  2. If you don't want to add GO code for versioning how about a VERSION file in the root path. Something that's created automatically from the release tag so when its cloned to a local repo we know the version of code we are dealing with?
  3. Are there autodocs generated for alpaca? if not would you like me to add the relevant bits so github will do it for you from the code?
  4. Would you rather I close this PR and discuss this another way?
samuong commented 2 years ago

What you're saying makes sense, and versioning is something I've been thinking about for a while (see #11) but haven't gotten around to yet. There is no version string anywhere in the code, and I'd like to avoid that if possible. The reason is that they can get in the way of merges, or just forgotten about.

I'm currently thinking that the best way to do this is to pass the output of git describe --tags to go via ldflags from GitHub Actions and/or look at the vcs.revision (and vcs.modified) setting in the BuildInfo.

I'm not sure exactly what autodocs you'd need; let's continue the conversation over email? I use Gmail and my username there is the same as my GitHub username.

rtfmoz2 commented 2 years ago

What you're saying makes sense, and versioning is something I've been thinking about for a while (see #11) but haven't gotten around to yet. There is no version string anywhere in the code, and I'd like to avoid that if possible. The reason is that they can get in the way of merges, or just forgotten about.

I'm currently thinking that the best way to do this is to pass the output of git describe --tags to go via ldflags from GitHub Actions and/or look at the vcs.revision (and vcs.modified) setting in the BuildInfo.

I'm not sure exactly what autodocs you'd need; let's continue the conversation over email? I use Gmail and my username there is the same as my GitHub username.

I found I can get the version using git describe --tags | head -1