NicoHood / GPGit

A shell script that automates the process of signing Git sources via GPG
MIT License
92 stars 10 forks source link

added support for BSD based systems (specifically, OS X with homebrew getopt #19

Closed wolph closed 3 years ago

wolph commented 4 years ago

On BSD/OS X the getopt command works differently so instead of parsing the arguments you get the original arguments back. On previous systems I've simply changed my PATH to fix it but I thought a better fix would be to check for it in the code :)

NicoHood commented 3 years ago

Hey @WoLpH It seems I completely missed this PR. Thanks for taking the time to share your patch!

I recently pushed some more bugfixes and changes (changelog will be updated soon, so you can follow better). It would be nice, if you can give it a test on BSD. I will try to integrate your changes from this PR as well.

NicoHood commented 3 years ago

I've adopted the fix here, can you please verify it is working? https://github.com/NicoHood/gpgit/commit/ab76a7e6752bab3320ffe59399a4350da9414267

wolph commented 3 years ago

It mostly appears to be working. But I am getting this error (although I think it's unrelated to this change):

==> ERROR: Github API message: 'Problems parsing JSON' Check your token configuration: https://github.com/settings/tokens

No clue what's causing it. I already tried to update my token but no dice.

NicoHood commented 3 years ago

Could you please post the terminal output? You can also try with --debug, but please remove any sensible information first (like the token).

NicoHood commented 3 years ago

I've tried to fix it via https://github.com/NicoHood/gpgit/commit/ae0a3ffa12712b2435214df43fb8d5332ecd1287 You can test the dev branch. I assume that one of the parameters you were using were not escaped properly. Did you use a custom name, tag or message?

wolph commented 3 years ago

Yes, that was probably it. The new release works perfect! Thank you for the fix :)

NicoHood commented 3 years ago

I've published a new release with the fix.

Could you maybe help me write some installing instructions for those systems? Mainly the command to install the dependencies and their correct name would be important.

I also want to add a feature that checks the key expire date. Now I found that date is different for gnu vs Mac/BSD Systems. You'd need to use gdate (gnu date) there instead, similar to getopt. I might get back to you if I need further help or testing with this.

wolph commented 3 years ago

Sure, it's rather simple I believe :)

  1. Install Homebrew: https://brew.sh/
  2. Install gnu-getopt: brew install gnu-getopt
  3. Install coreutils for gnu date: brew install coreutils

And that's it :)

Optionally (if people don't have it yet)

  1. brew install git
  2. brew install curl

Or an all-in-one command: brew install curl git gnu-getopt coreutils

wolph commented 3 years ago

@NicoHood still not perfectly fixed unfortunately. The issue is with quotes in MESSAGE that completely breaks.

wolph commented 3 years ago

Actually... this seems to fix it for me:

SAFE_MESSAGE=${MESSAGE//$'\n'/'\n'}
SAFE_MESSAGE=${SAFE_MESSAGE//\"/\\\"/}
API_JSON="$(printf '{"tag_name": "%s","target_commitish": "%s","name": "%s","body": "%s","draft": false,"prerelease": %s}' \
           "${TAG}" "${BRANCH}" "${TAG}" "$SAFE_MESSAGE" "${PRERELEASE}")"
NicoHood commented 3 years ago

Can you name me a sample message, that does not work for you? I've replaced printf with jq, it should escape everything. I am wondering why this still does not work properly.

wolph commented 3 years ago

I've recently switched to MESSAGE=$(git log -1)

commit 638f67af428413ef6b2a45633b6e4f034b11f272
Merge: ad33bc1 061837e
Author: Rick van Hattem <Wolph@wol.ph>
Date:   Wed Feb 3 02:10:59 2021 +0100

    Merge tag 'v2.2.1' into develop

    removed debug statement v2.2.1

    # gpg: Signature made Wed Feb  3 02:10:59 2021 CET
    # gpg:                using RSA key 149325FD15904E9C4EB89E95E81444E9CE1F695D
    # gpg: Good signature from Rick van Hattem <wolph@wol.ph> [ultimate]
    # gpg:                 aka [jpeg image of size 9662] [ultimate]
NicoHood commented 3 years ago

Why would you do this? This message also gets attached to the tag and the github message.

Did you see, that I've added automatically parsing of a changelog file in 1.4.x? I am currently working a lot on this project, including a website etc, so everything will be (hopefully) more clear soon. Maybe that feature could be useful for you too.

wolph commented 3 years ago

Because Github doesn't show the tag commit message in the list of releases: https://github.com/WoLpH/python-utils/releases That output is pretty useless.

So changed it to look like this: https://github.com/WoLpH/portalocker/releases I still need to add the mesage to the title it seems, but it's already far more useful.

I didn't know about the changelog parsing, but I'm not using a separate changelog anyhow. The tag commit messages are my changelog.

NicoHood commented 3 years ago

I am not sure if I understand correct.

Did you try the -m option? `gpgit 1.0.0 -m "This is my tag message. Here I can add a changelog for example."

Also looking at your post above you said you are using MESSAGE=$(git log -1). Did you edit the code directly? If yes, the issue is possibly related to missing quotes: MESSAGE="$(git log -1)", but even better is to not modify the script and use gpgit 1.0.0 -m "$(git log -1)".

I am still wondering what useful information git log -1 contains. This sounds like nothing important, but I might be wrong. Keep A Changelog has some good arguments, why a dedicated changelog makes sense.

Did that help or am I still completely missing something?

Offtopic: Is there any reason why you are tagging releases with "v" v1.0.0 prefix? Cause that is currently not supported for parsing changelogs. I can think of some reasons, but want to hear your opinion as well ;-)

wolph commented 3 years ago

I am not sure if I understand correct.

Did you try the -m option? `gpgit 1.0.0 -m "This is my tag message. Here I can add a changelog for example."

Also looking at your post above you said you are using MESSAGE=$(git log -1). Did you edit the code directly? If yes, the issue is possibly related to missing quotes: MESSAGE="$(git log -1)", but even better is to not modify the script and use gpgit 1.0.0 -m "$(git log -1)".

Let me clarify a bit :)

I use git-flow release to create releases and in the post-flow-release-finish hook I have the following to tell gpgit to create a release:

MESSAGE=$(git log -1)

# Implement your script here.
gpgit $VERSION -m "$MESSAGE"

Perhaps I should replace it with MESSAGE=$(git tag -n9 $VERSION) instead. For now it was just a quick way to get something useful in the github releases.

I am still wondering what useful information git log -1 contains. This sounds like nothing important, but I might be wrong. Keep A Changelog has some good arguments, why a dedicated changelog makes sense.

My git tags are the changelog in this case. It contains all of the relevant changes made in the releases.

While I agree that dedicated changelogs are better... I know I'll forget and having an out of date changelog is worse than not having a dedicated one. Besides slightly different formatting it's effectively the same.

Offtopic: Is there any reason why you are tagging releases with "v" v1.0.0 prefix? Cause that is currently not supported for parsing changelogs. I can think of some reasons, but want to hear your opinion as well ;-)

It's mostly legacy now to be honest. Originally it was because some software automatically tries to convert it into a number which fails because there are 2 dots.

wolph commented 3 years ago

I think I do have a little feature request. It would be nice to be able to set the release title as well. That seems to be hardcoded to the tag right now.

NicoHood commented 3 years ago

Thanks for the feedback. I've opened separated bugs for this.