This open-prs command should be able to reject the current user before creating the PR. A first call should be done in the beginning so the current user gets rejected. The remaining reviewers should still be added to the PR.

I'm posting it here so we won't forget about this idea. Probably to be done either in this project, maybe in https://github.com/metanorma/metanorma-release.

It would be best if we can centrally manage the badges. We have been centrally managing our GitHub Actions using the [https://github.com/metanorma/cimas/](Cimas gem) with the CI files located https://github.com/metanorma/metanorma-build-scripts/tree/master/cimas-config.

Originally posted by @ronaldtse in metanorma/metanorma-release#4 (comment)

Right now, if the "groups" configuration contains a repo that is not reflected in the "repositories" section, the command will crash.

e.g.

# cimas pull -f $CIMAS_CONFIG -r $CIMAS_WD -g samples
Pulling from mn-samples-iso...
Pulling from mn-samples-gb...
Pulling from mn-samples-mpf...
Error: undefined method `[]' for nil:NilClass
/Users/me/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/cimas-0.1.0/lib/cimas/cli/command.rb:253:in `block in pull'
/Users/me/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/cimas-0.1.0/lib/cimas/cli/command.rb:250:in `each'

The reason is repo is set to nil (repo_by_name can't find the repo), and repo['branch'] crashes.

A startup configuration file check will prevent these errors.

In fact, the way to resolve this is to model Repository, Group and Settings separately as Ruby Classes and on parsing the configuration file, these errors can be detected.

Some repositories contain very similar but different Makefiles, such as iso-10303-2 -- it has some targets that are specific to it, such as for file generation outside Metanorma.

Is it possible to have some hidden file, e.g. .cimas-block so that Cimas doesn't update it (i.e. even if we kept it in the config, it still doesn't update it)?

The --verbose option is supported but doesn't currently do anything. This issue is to fix that.

As annual update. Also, need to update Rubocop config to have minimum of 3.0.x, and presumably add priority validation rules for it.

Right now Cimas only works with GitHub. We should extend it so it also works with GitLab.

We have enough repositories on GitLab to warrant this.

Since updating the build scripts to the latest, LateXML no longer builds on MacOS: Perl library XML::LibXSLT fails to install during execution.

https://github.com/metanorma/metanorma-standoc/runs/394188796

Have upgraded Ruby in gemspecs for Metanorma. There is now a discrepancy with the rubocop config.

This is a bug to fix.

$ cimas push -f $CIMAS_CONFIG -r $CIMAS_WD   -b cimas-initial-run -m 'Cimas initial run'
...
Skipping commit on relaton-omg, no changes detected.
...

$ cd ../relaton-omg/
$ git status
On branch cimas-initial-run
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	new file:   .github/workflows/macos.yml
	new file:   .github/workflows/ubuntu.yml
	new file:   .github/workflows/windows.yml

The new files should have been committed during the push command and no staging changes should appear.

Additionally this git output may be a consideration after the commit is made:

fatal: The current branch cimas-initial-run has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin cimas-initial-run

We will be using Gemfile.devel from now on to ensure that PRs under development import the correct dependencies for GHA. So excluding Gemfile.devel through gitignore would be counterproductive.

It would be nice if we could ensure that Gemfile.devel is never included in a release, but I don't know if that should be locally implemented code, through rake.

We have switched the default branch of most metanorma repositories from master to main.

If a repository still has been left on master, or if it was created from the beginning as main, the "commits since this release" header still displays:

https://github.com/metanorma/html2doc/releases/tag/v1.1.2
https://github.com/metanorma/metanorma-utils/releases/tag/v1.2.2

However, for repositories like metanorma-standoc, where we have shifted the default repository, the header no longer displays:

https://github.com/metanorma/metanorma-standoc/releases/tag/v1.9.3

This makes it difficult to compile release notes.

This is a known issue, and the best Github has come up with is a workaround in the GitHub actions config for the repository, whereby release workflows (such as rake release) need to trigger release creation on the GitHub API, using the target_commitish parameter:

https://github.community/t/x-commits-to-master-since-this-release-is-missing/618/9
https://github.community/t/bug-commit-since-release-doesnt-use-default-branch-master-hardcoded/155923/11
https://github.com/actions/create-release/blob/main/README.md for example workflow

It looks like @w00lf had hard coded these to the build scripts, but had not informed you to update them, so they got wiped when I did the build script updates: metanorma/reverse_adoc@7262ce9#diff-a77b4f53dac18d1e289021f245022811

Could you please update the build scripts against what @w00lf had earlier?

@w00lf: as I'd indicated, the build scripts (.github/workflows/*.yml) are updated by @CAMOBAP795 and automatically propagated throughout Metanorma when the ci-master script is run. That's why you can't update those scripts manually.

Fix this.

This issue is to utilize Octokit's:

• pull_requests to filter by specified branch
• merge_pull_request on each PR found

To "merge all PRs" of a certain branch:

• If not all tests pass, a --allow-failed-prs option should still merge them.
• If not all PRs are approved, a --merge-unapproved-prs option will still merge them.

It should use this documentation.

==== `cimas merge-prs`

The `merge-prs` sub-command:

* merges the approved Pull Requests filtered by the given branch;
* allows merging un-approved PRs if the `--merge-unapproved-prs` option is given;
* allows merging failed Pull Requests if the `--allow-failed-prs` option is given.

Since this command depends on GitHub privileged functionality,
you must supply your GitHub Personal Access Token (PAT)
via the `GITHUB_TOKEN` environment variable.

[source,sh]
----
GITHUB_TOKEN=deadbeefdeadbeef; \
cimas merge-prs -f {cimas-config-file} -r {cimas-working-area} \
  -b {branch-of-pr-to-approve} \
  -m {pr-merge-message} \

# e.g.
# cimas merge-prs -f cimas.yml -r ~/src/cimas-wd \
#   -b my-new-ci-branch \
#   -m 'My merge message' \
#   [-g {group1,group2,...}]
----

NOTE: This sub-command is considered "`irreversible`" as it
alters the state of GitHub repositories by approving
pull requests.

This issue is to utilize Octokit's:

• pull_requests to filter by specified branch
• create_pull_request_review on each PR found
• submit_pull_request_review on each PR found

To "approve the previous PRs" of a certain branch (if they pass all tests). If not all tests pass, a --allow-failed-prs option should still approve them.

It should use this documentation.

==== `cimas approve-prs`

The `approve-prs` sub-command:

* approves the Pull Requests filtered by the given branch if they pass all tests;
* allows approving failed Pull Request tests if the `--allow-failed-prs` option is given.

Since this command depends on GitHub privileged functionality,
you must supply your GitHub Personal Access Token (PAT)
via the `GITHUB_TOKEN` environment variable.

[source,sh]
----
GITHUB_TOKEN=deadbeefdeadbeef; \
cimas approve-prs -f {cimas-config-file} -r {cimas-working-area} \
  -b {branch-of-pr-to-approve} \
  -m {pr-approval-message} \

# e.g.
# cimas approve-prs -f cimas.yml -r ~/src/cimas-wd \
#   -b my-new-ci-branch \
#   -m 'My pull-request message' \
#   [-g {group1,group2,...}]
----

NOTE: This sub-command is considered "`irreversible`" as it
alters the state of GitHub repositories by approving
pull requests.

... and for the gems using XSL:FO PDF: nist, iec, iso, itu, unece.

The tickets to port that functionality into the three OS's are:

metanorma/chocolatey-metanorma#38
https://github.com/metanorma/metanorma-macos-setup/issues/9
metanorma/metanorma-linux-setup#21

The recent modifications to used cached gems, in the feature/bundler-cache-and-brew-install-metanorma branches, have made compilation much quicker. However they have introduced a new problem.

The release of the multiple gems generated by our team needs GitHub Actions to receive up to date releases of our own gems, since they are released in succession, and pre-release testing of one depends on the release of the gems it depends on. In the case of MacOs and Ubuntu, there is a lag of at least 32 hours between release and the cache being updated.

The simplest solution here is to except all metanorma, relaton, plurimath gems from caching, and to fetch them direct from rubygems to GitHub Actions. Somehow.

It is cumbersome to specify files for each individual repo. We could allow files to be specified under groups to make this simpler. All we need is to merge the group-specified files together with individual repo overrides within the sync method.

The lint sub-command is disabled as it isn't that useful for now.

This task is to restore it in a working form.

cimas 0.2.0 built to pkg/cimas-0.2.0.gem.
Tag v0.2.0 has already been created.
Pushing gem to https://rubygems.org.../
You do not have permission to push to this gem. Ask an owner to add you with: gem owner cimas --add [email protected]
Error: Process completed with exit code 1.

Full log: https://github.com/metanorma/cimas/actions/runs/9172420822/job/25218877158#step:10:19

ci-master used to support force-push functionality that allows changes to be merged into the last commit using git commit --amend.

This issue is to restore this functionality.

The CLI right now is terribly done. We should use Thor instead.

The Cimas working directory is just a directory containing repos, and the Git operations across repos can be performed independently.

This issue is to allow simple parallel processing of Git repos (e.g. Ruby Fiber); an option specifying parallity will be useful.

https://github.com/metanorma/html2doc/actions/runs/3384179124

rake / prepare

Node.js 12 actions are deprecated. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/. Please update the following actions to use Node.js 16: actions/checkout, actions/checkout
 
The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

The `save-state` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

The Node.js 12 warning also appears before all normal tests:

Node.js 12 actions are deprecated. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/. Please update the following actions to use Node.js 16: actions/checkout, actions/checkout

From metanorma gem, running rubocop:

Warning: obsolete parameter `IgnoredMethods` (for `Metrics/BlockLength`) found in /Users/nickn/Documents/Arbeit/upwork/ribose/metanorma/.rubocop-https---raw-githubusercontent-com-riboseinc-oss-guides-master-ci-rubocop-yml
`IgnoredMethods` has been renamed to `AllowedMethods` and/or `AllowedPatterns`.
Warning: Metrics/BlockLength does not support IgnoredMethods parameter.

Supported parameters are:

  - Enabled
  - CountComments
  - Max
  - CountAsOne
  - AllowedMethods
  - AllowedPatterns
  - Exclude

Warning: obsolete parameter `IgnoredMethods` (for `Metrics/BlockLength`) found in /Users/nickn/Documents/Arbeit/upwork/ribose/metanorma/.rubocop.yml
`IgnoredMethods` has been renamed to `AllowedMethods` and/or `AllowedPatterns`.
Warning: Metrics/BlockLength does not support IgnoredMethods parameter.

Supported parameters are:

  - Enabled
  - CountComments
  - Max
  - CountAsOne
  - AllowedMethods
  - AllowedPatterns
  - Exclude