Initial build of action

[webstech]

This action supports a number of commands and would be part of scheduled GitHub workflows to perform the commands. These actions are supporting gitgitgadget functions that allow email patch based repos to work with GitHub.

All input is welcome. The doc probably suffers from author familiarity issues. The README is generated from the actions.yml using a randomly selected tool. If there are known alternatives, let me know.

[dscho]

This is a great start!

Just to make sure: you are planning on using something like https://github.com/marketplace/actions/action-github-app-token to generate the token in the workflow, right? I wonder whether it wouldn't make sense to fold that functionality into the Action, given that gitgitgadget already contains code to do that.

Speaking of the Action, how about renaming it from check-status to gitgitgadget-action? That would help with forks (speaking from experience, people who fork git-for-windows/build-extra hate that their fork's name does not have git-for-windows in its name, as they are prone to forget what that particular repository is all about after a couple of years).

[dscho]

Peter Evans? 😁

Oh, and 2019. Wasn't that looong, looooong time ago, like a life time ago?

[webstech]

Please point to a preferred licence.

[dscho]

I'm fine with MIT. Or with ISC. Just change the name and the year ;-)

[dscho]

How about specifying it directly, i.e. as a link to the repository?

[webstech]

I was avoiding checking in the package as part of gitgitgadget. Assumed there would be very little need for it. The instructions identify how to create it. It can be added to ggg if that is preferred. The package could also be published to npm, etc. if that is a preferred direction. Trying to limit the spread on something with limited use.

OTOH, did I misunderstand your suggestion?

[dscho]

I thought that we could simply refer to the gitgitgadget/gitgitgadget repository without changing anything in that repository, is that not the case? Would we have to commit transpiled code?

[dscho]

According to https://docs.npmjs.com/cli/v8/configuring-npm/package-json#git-urls-as-dependencies:

When installing from a git repository, the presence of certain fields in the package.json will cause npm to believe it needs to perform a build.
[...]
build
[...]
install

I therefore think that it should simply work, no changes in gitgitgadget/gitgitgadget required.

[webstech]

What is needed to build the action are the gitgitgadget lib source files. The npm pack makes them available with the deps info. Having npm run a build is not going to make those files available as far as I can tell (no, I did not run a test). The npm build feature seems like a way to make tools available that have not been published to a package manager.

[dscho]

The npm build feature seems like a way to make tools available that have not been published to a package manager.

Yes, and I think that is our use case. I should have a little bit of time to play with this next week.

[webstech]

Yes, and I think that is our use case.

Well, sort of. From the doc it appears npm will do a build that we don't need. It then does the pack (or equivalent) and installs that. I was concerned it would try to use the build output but someone (okay, me) added files to the package.json and it all works. I will update the package.json and README.md to show this simpler process.

Thanks for catching this and I guess I should have run that test.

[webstech]

Just to make sure: you are planning on using something like https://github.com/marketplace/actions/action-github-app-token to generate the token in the workflow, right? I wonder whether it wouldn't make sense to fold that functionality into the Action, given that gitgitgadget already contains code to do that.

That looks interesting but doing it internally is probably better. Non-gitgitgadget projects may not have an app_id so they will also need to be supported. I will look into this some more. It may mean more optional parameters.

Speaking of the Action, how about renaming it from check-status to gitgitgadget-action? That would help with forks (speaking from experience, people who fork git-for-windows/build-extra hate that their fork's name does not have git-for-windows in its name, as they are prone to forget what that particular repository is all about after a couple of years).

How about gitgitgadget-action-check-status? gitgitgadget-action-handle-pr is in progress.

[webstech]

@dscho Thanks for the prompt review. This is one piece of many.

[dscho]

Speaking of the Action, how about renaming it from check-status to gitgitgadget-action? [...]

How about gitgitgadget-action-check-status?

Why check-status? According to action.yml this Action supports many modes, none of which really fit into the description of "checking a status". I think I really like gitgitgadget-action better...

[webstech]

Why check-status? According to action.yml this Action supports many modes, none of which really fit into the description of "checking a status". I think I really like gitgitgadget-action better...

I thought the actions were checking the status of the notes vs reality and the status of email tracking. It may be a simplistic view (it could easily have been update-status). The problem I have with gitgitgadget-action is that there are multiple actions (handling PRs being another, and maybe auth as well). With that in mind, I am open to other suggestions. In the end, we either remember the name or scowl and check the readme. 🙁

[webstech]

That looks interesting but doing it internally is probably better. Non-gitgitgadget projects may not have an app_id so they will also need to be supported. I will look into this some more. It may mean more optional parameters.

Forgot I had done a similar implementation in the package branch of my ggg repo. Guess I had a good vacation! Either way, a token of some sort is needed (to generate a token or the real token). Maybe both can be supported - testing is easier without needing to have the app.

[dscho]

Guess I had a good vacation!

😁

Either way, a token of some sort is needed (to generate a token or the real token). Maybe both can be supported - testing is easier without needing to have the app.

That makes sense.

[dscho]

Hey @webstech! After mulling over this for quite a few months, I think it would make most sense to fold this back into gitgitgadget/gitgitgadget with the following idea: make it a single GitHub Action (using ncc and such, as you did) that takes only two (or three) parameters: one to point to a file that contains the configuration as JSON, and another parameter to essentially contain the command-line that is currently passed to the misc-helper.ts script (the third parameter would contain the secret necessary to act as the GitHub App(s), but it is probably a better idea to implement that via environment variables).

That would solve a lot of headache I had about maintaining several Actions and the ensuing dependency hell.

What do you think?