Add scripts to collection

[v1gnesh]

There's a tool called multi-gitter, which allows any scriptable action to be repeated across the whole GitHub org, with conditions for selection, filtering, etc.

The script runs in the context of any repo's root dir. See docs at the link above for details.

In summary: Create bulk PRs Bulk PR merge Bulk PR close Bulk whatever

[IgorTodorovskiIBM]

Very nice find! Is multi-gitter next on your list of Go ports? ;)

I would suggest creating a bulk_changes subdir (or similar) so that we can manage all scripts that perform bulk changes under one dir. And perhaps a sample invocation of how to use multi-gitter on the ZOSOpenTools org (either as a comment or in a doc).

[MikeFultonDev]

Sounds great! Unfortunately I expect we will need to use it a fair amount! would this run on z/OS or Jenkins or either? I am thinking there might be instances where we have to run on z/OS to get info but typically would run off z/OS. Would we want to integrate this into a zopen plumber tool if on z/OS ?

[v1gnesh]

Unfortunately I expect we will need to use it a fair amount!

Nothing unfortunate about it :smiley: . Open source is a gift. If the thought is, "it's a dependency", the code can be forked.

We're still pretty pinned on things like Ant, Tomcat, etc. So reinventing/rewriting everything from scratch comes at the cost of being a lot slower.

Will try porting it to zOS. ~At this point, I think we're close to adding bump & multi-gitter to the meta package (alongside curl and jq).~

Would we want to integrate this into a zopen plumber tool if on z/OS ?

A starter config that zopen contrib's can kick off with.

[v1gnesh]

@IgorTodorovskiIBM Any chance you can give me access to create branches on all repos in this org? Nothing to create right now, but for the next time. Cleaning up forks is a lot of manual work :sweat_smile:

[DevonianTeuchter]

As a thought, are we almost at the point where we could have a meta-dev as well as a meta package, the latter being for general consumers, the former for those interested in porting packages?

[IgorTodorovskiIBM]

As a thought, are we almost at the point where we could have a meta-dev as well as a meta package, the latter being for general consumers, the former for those interested in porting packages?

Good idea. Some dev scripts like zopen-build depend on consumer scripts like zopen-install so we'd need to make sure we add meta as a runtime dependency in meta-dev. Would we want to do this only for the packages or also for the repos and separate the meta repo into two (meta and metadev)? I'd still prefer to keep everything under one monorepo, but perhaps we can move the dev tools to "devbin" and then in the metadevport package, we can add install logic to move the dev tools into the metadev/bin/ directory.

[MikeFultonDev]

Before we jump into creating another repo in the 'meta' category, can we list out the pros and cons? While I agree it could make the 'meta' package a bit thinner for consumers, are there other advantages? I see increased complexity in managing another repo and making sure they can be tested well together (having meta and metaport as two things is already a bit complicated and it would be interesting to see if we could improve on that). I am also thinking it would be a good time to do a spring clean of zopen-build. It has stuff in it that I think we can retire now (a bunch of old env vars we have now eliminated the need for like ZOPEN_TARBALL_xxx and ZOPEN_GIT_xxx

[v1gnesh]

As far as this PR goes, it doesn't need a meta-dev; just that build_and_test.yml and bump.yml need to be available somewhere locally, where the multi-gitter script is being executed. So that it can copy those into the missing repos and create PRs with it.

Thinking out loud... rather than meta-dev, how about a 'mode' we can switch into, with existing meta? That way, the extra bits still live in meta, but it can be instructed to behave differently.

[IgorTodorovskiIBM]

As far as this PR goes, it doesn't need a meta-dev; just that build_and_test.yml and bump.yml need to be available somewhere locally, where the multi-gitter script is being executed. So that it can copy those into the missing repos and create PRs with it.

Thinking out loud... rather than meta-dev, how about a 'mode' we can switch into, with existing meta? That way, the extra bits still live in meta, but it can be instructed to behave differently.

Reminds me of brew's "developer mode" - https://docs.brew.sh/Manpage#developer-subcommand. We should create a discussion to discuss this further.

[v1gnesh]

@IgorTodorovskiIBM Any chance you can give me access to create branches on all repos in this org? Nothing to create right now, but for the next time. Cleaning up forks is a lot of manual work 😅

Speaking of... @IgorTodorovskiIBM could you give me write access to the repos in the org? With branch protection on main of course.

[v1gnesh]

Now added

• a script that, via multi-gitter
  • using the config cicd/multi-gitter-config
  • looks for bump.yml in most ZOSOpenTools repos
  • checks the state of this workflow with gh cli
  • if it's disabled, re-enable it with gh cli
• actions/multi-gitter-action/action.yml, to be used from
• .github/workflows/enable_disabled_workflow.yml to do this on the 2nd of every month

Have a look at https://github.com/v1gnesh/mig/actions/workflows/enable_disabled_workflow.yml for a worked example.

[v1gnesh]

@IgorTodorovskiIBM Any thoughts on this? https://github.com/ZOSOpenTools/meta/actions/runs/8166502621/job/22325352934#step:5:62

multi-gitter requires just 'repo' & 'workflow' access in the token. The first step ('Set up Job') from the workflow log shows that the GITHUB_TOKEN does have Action: write.

[IgorTodorovskiIBM]

For below, I compared the settings for nanoport and libpipelineport and I'm not seeing any difference. Do you get the same result when rerunning?

time="2024-03-06T03:25:30Z" level=info msg="Script output: ----------------\n" repo=ZOSOpenTools/nanoport
time="2024-03-06T03:25:30Z" level=info msg="Script output: {\"message\":\"Resource not accessible by integration\",\"documentation_url\":\"https://docs.github.com/rest/actions/workflows#enable-a-workflow\"}gh: Resource not accessible by integration (HTTP 403)\n" repo=ZOSOpenTools/libpipelineport

[v1gnesh]

Launched a rerun now, and it looks the same. EDIT: The ordering of messages are jumbled because of the concurrent runs.

https://github.com/ZOSOpenTools/meta/actions/runs/8182147728/job/22373038482

One stackoverflow comment says, "go to https://github.com/OWNER/REPO/settings/actions and in Workflow Permissions section give actions Read and Write permissions. That provides your token with rights to modify your repo and solves your problem". If we can set this for one repo (nano or libpipeline for example), then we can confirm if this works in a rerun of this workflow.

[IgorTodorovskiIBM]

Hmm, I checked that earlier and it does have it:

[v1gnesh]

:thinking: Maybe it's needed in meta's Action settings?