Add support for git-xargs registered environment variables based on arguments and flags

andyfeller commented 1 year ago

Description

Fixes #115.

These changes add support for git-xargs registered environment variables based on arguments and flags intended for use by the commands and scripts called by git-xargs. These environment variables start with XARGS_ to avoid collision with other use cases and include:

XARGS_DRY_RUN: whether --dry-run flag was provided
XARGS_REPO_NAME: the name of the target repository being processed
XARGS_REPO_OWNER: the owner of the target repository being processed

TODOs

Read the Gruntwork contribution guidelines.

[x] Update the docs.
[x] Run the relevant tests successfully, including pre-commit checks.
[x] Ensure any 3rd party code adheres with our license policy or delete this line if its not applicable.
[x] Include release notes. If this PR is backward incompatible, include a migration guide.

Release Notes (draft)

Added support for environment variables registered by git-xargs based on flags and arguments

Migration Guide

carusooo commented 1 year ago

This would address my use-case. Very much appreciated

andyfeller commented 1 year ago

cc: @karlwithak1

zackproser commented 1 year ago

@andyfeller Thanks for your PR! Your changes LGTM, so I've kicked off tests

zackproser commented 1 year ago

@andyfeller would you kindly chmod +x your test-env-var script - then tests should pass! Thanks

andyfeller commented 1 year ago

@zackproser : I'm currently working on my personal laptop being out of office, the script appears to match the permissions of the others on WSL:

andyfeller@WIN-29L6KJF8DED:/mnt/c/Users/andre/Documents/Workspace/andyfeller/git-xargs/data/test/_testscripts$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.3 LTS
Release:        20.04
Codename:       focal
andyfeller@WIN-29L6KJF8DED:/mnt/c/Users/andre/Documents/Workspace/andyfeller/git-xargs/data/test/_testscripts$ ls -l
total 4
-rwxrwxrwx 1 andyfeller andyfeller 1249 Jun 28 08:29 add-license.sh
-rwxrwxrwx 1 andyfeller andyfeller   83 Jun 28 08:29 bad-perm.sh
-rwxrwxrwx 1 andyfeller andyfeller  306 Jun 28 09:30 test-env-vars.sh
-rwxrwxrwx 1 andyfeller andyfeller   59 Jun 28 08:29 test-python.py
-rwxrwxrwx 1 andyfeller andyfeller   55 Jun 28 08:29 test-ruby.rb
-rwxrwxrwx 1 andyfeller andyfeller  293 Jun 28 08:29 test-stdout-stderr.sh

This appears to differ on Git Bash for Windows:

andre@WIN-29L6KJF8DED MINGW64 ~/Documents/Workspace/andyfeller/git-xargs/data/test/_testscripts (issue-115-env-vars)
$ ll
total 9
-rwxr-xr-x 1 andre 197609 1249 Jun 28 08:29 add-license.sh*
-rwxr-xr-x 1 andre 197609   83 Jun 28 08:29 bad-perm.sh*
-rwxr-xr-x 1 andre 197609  306 Jun 28 09:30 test-env-vars.sh*
-rwxr-xr-x 1 andre 197609   59 Jun 28 08:29 test-python.py*
-rwxr-xr-x 1 andre 197609   55 Jun 28 08:29 test-ruby.rb*
-rwxr-xr-x 1 andre 197609  293 Jun 28 08:29 test-stdout-stderr.sh*

When trying to change the mode of the file, git is saying there are no changes to be committed 😞. I know this might be a Windows / Linux / Mac translation issue, so I'd appreciate a hand as I won't be back on my work machine until this weekend at the earliest.

andyfeller commented 1 year ago

Trying to utilize git update-index to force the issue with windows:

$ git update-index --chmod=+x test-env-vars.sh

zackproser commented 1 year ago

Thanks, Andy! LGTM, so approving and merging.

zackproser commented 1 year ago

@andyfeller Thanks again - https://github.com/gruntwork-io/git-xargs/releases/tag/v0.1.9 is the latest release that will have your changes. v0.1.8 had a build issue related to the Go version, which I bumped in a subsequent release.

andyfeller commented 1 year ago

@zackproser : thank you and thank you for OSSing your work for others ✨ I hope to contribute back more, an example of a wrapper script that will demonstrate calling multiple commands and scripts.

In my use case, I have repositories created from a template, which has been updated with new files that the children should get. Additionally, there have been new issue / PR labels I want to push out, which is was somewhat difficult without this PR due to knowing if --dry-run.

zackproser commented 1 year ago

@andyfeller Thanks so much for your kind words. It is my sincere pleasure.

That sounds terrific and I'd bet many others would benefit from that as well. I initially had this scripts folder here thinking it might be a decent place for the community to compile such scripts / examples - but perhaps those belong in a separate repo? Not sure.

andyfeller commented 1 year ago

@zackproser : finally finished refactoring my initial prototype wrapping around git-xargs and released it as a GitHub CLI extension: https://github.com/andyfeller/gh-publicize

I'd love to chat a bit regarding your thoughts, can open an issue or discussion.

zackproser commented 1 year ago

@andyfeller Wow! This looks super cool - I especially love the fact you made it a gh extension - I've found those to work really well in the past. I love the proposed use cases you have as well - they all make a ton of sense and were part of what originally urged us on to write git-xargs.

Speaking of which - one other idea I always thought would be awesome in conjunction with this stuff is some kind of light engine that could provide the git diff between some desired state and the current state of a given repo - which could output git-xargs or gh-publicize instructions / API calls - to essentially open the PRs which would get your repos all up to date and compliant with what you've set as your template repo - if I'm making sense.

One logistical note - I'm no longer working at Gruntwork, so I'm unlikely to have time to return to this anytime soon, but I'll bet @brikis98 would be keen to know about this as well.

Seriously - very cool work :tada:

andyfeller commented 1 year ago

Speaking of which - one other idea I always thought would be awesome in conjunction with this stuff is some kind of light engine that could provide the git diff between some desired state and the current state of a given repo - which could output git-xargs or gh-publicize instructions / API calls - to essentially open the PRs which would get your repos all up to date and compliant with what you've set as your template repo - if I'm making sense.

So is this less of a push model and more of a pull? A process that reverse engineers what it is missing to match the source repository in question, yeah?

One logistical note - I'm no longer working at Gruntwork, so I'm unlikely to have time to return to this anytime soon

Congratulations on the new adventure! Happy to talk shop with others as I appreciate the work here ❤️

zackproser commented 1 year ago

@andyfeller :joy: Precisely - your gif game is on point!

gruntwork-io / git-xargs