Git Product home page Git Product logo

ci's Introduction

Metanorma: the standard for standards

Gem Version Build Status Code Climate Pull Requests Commits since latest

Metanorma is dedicated to harmonizing standard documents produced by different standard-setting bodies in a manner that maintains correct semantics while allowing each standard publisher to define appropriate semantic extensions.

Simply put, it allows standards bodies or any other organization to create their own standard or specification document in a best practices manner.

Metanorma is composed of a number of specifications and software implementations. The Metanorma document model is based on the SecureDoc document model.

For more on Metanorma and who uses it, refer to https://www.metanorma.org

Installation on supported platforms

Installing individual components

The Metanorma workflow can be utilized via the metanorma-cli Ruby gem.

gem install metanorma-cli

Usage

Threaded execution

Metanorma has threaded execution, to generate output documents from the same Presentation XML input more quickly. Similar to relaton, the METANORMA_PARALLEL environment variable can be used to override the default number of parallel fetches used.

Origin of name

Meta- is a prefix of Greek origin ("μετα") for “with” “after”. In English, it has ended up meaning "about (its own category)"; e.g. meta-discussion (a discussion about discussion). (For the roundabout way it ended up with that meaning, see https://en.wikipedia.org/wiki/Meta#Etymology.)

Norma is Latin for “rule” and “standard”; hence English norm, but also German Norm "standard".

The Metanorma project is for setting a standard for standard documents created by standards-setting organizations (which is a meta thing to do); hence this name.

Metanorma seeks to embrace all standards documents standards, but not possess any: it can give rise to many "standard" standards, but not limit the extension of any of those standards.

The motto of the project is Aequitate verum, "Truth through equity". Dealing with all standards fairly (aequitate), we seek not an abstract virtue (veritas), but a practical reality on the ground (verum), that can be used by stakeholders of multiple standards.

ci's People

Contributors

abunashir avatar alexeymorozov avatar camobap avatar ni4 avatar opoudjis avatar ribose-jeffreylau avatar ronaldtse avatar suleman-uzair avatar

Stargazers

 avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Forkers

gaybro8777 ni4

ci's Issues

Travis Ubuntu install of metanorma is now over 10 minutes

Typically the script is run like this:

sudo bash -c "curl -L https://raw.githubusercontent.com/metanorma/metanorma-linux-setup/master/ubuntu.sh | bash"
  1. There's lots of LaTeXML tests being run
  2. Node install takes a long time
  3. Compilation of libsass takes a long time
  4. The logs become very long (the installation logs should be cut down or at least folded)

No tests on pull requests?

Is there any good reason for:

on: [push]

instead of:

on: [push, pull_request]

Running tests on push event will run tests on the last commit of given branch, but will not take into account commits, which are present on master branch, but not on tested branch. Also, I suppose, no tests will be run for pull requests coming from forked repositories.

plantuml installation via brew extremely slowdown CI

The solution which was introduced by me brew install plantuml take much more time in comparison with the previous one

  - unset _JAVA_OPTIONS
  - wget "http://downloads.sourceforge.net/project/plantuml/plantuml.jar?r=&ts=1424308684&use_mirror=jaist" -O plantuml.jar
  - sudo mkdir -p /opt/plantuml
  - sudo cp plantuml.jar /opt/plantuml
  - echo "#! /bin/sh" > plantuml.sh
  - echo 'exec java -jar /opt/plantuml/plantuml.jar "$@"' >> plantuml.sh
  - sudo install -m 755 -D plantuml.sh /usr/bin/plantuml
  - plantuml -version

I need to check it on OSX and try different URL (maybe https://vorboss.dl.sourceforge.net/project/plantuml/1.2019.4/plantuml.1.2019.4.jar) to download because the current one takes up to 1 min to get it

ietf related repos timeout

Problem

For IETF related repositories:

We often see timeouts like:

Reading workgroups from https://tools.ietf.org/wg/...
bundler: failed to load command: metanorma (/Users/runner/work/mn-templates-ietf/mn-templates-ietf/vendor/bundle/ruby/3.0.0/bin/metanorma)
/Users/runner/work/mn-templates-ietf/mn-templates-ietf/vendor/bundle/ruby/3.0.0/gems/metanorma-ietf-2.3.1/lib/asciidoctor/ietf/validate.rb:48:in `initialize': No such file or directory @ rb_sysopen - https://tools.ietf.org/wg/ (Errno::ENOENT)
	from /Users/runner/work/mn-templates-ietf/mn-templates-ietf/vendor/bundle/ruby/3.0.0/gems/metanorma-ietf-2.3.1/lib/asciidoctor/ietf/validate.rb:48:in `open'
	from /Users/runner/work/mn-templates-ietf/mn-templates-ietf/vendor/bundle/ruby/3.0.0/gems/metanorma-ietf-2.3.1/lib/asciidoctor/ietf/validate.rb:48:in `cache_workgroup_ietf'
	from /Users/runner/work/mn-templates-ietf/mn-templates-ietf/vendor/bundle/ruby/3.0.0/gems/metanorma-ietf-2.3.1/lib/asciidoctor/ietf/validate.rb:75:in `block in cache_workgroup'
	from /Users/runner/work/mn-templates-ietf/mn-templates-ietf/vendor/bundle/ruby/3.0.0/gems/metanorma-ietf-2.3.1/lib/asciidoctor/ietf/validate.rb:74:in `open'
	from /Users/runner/work/mn-templates-ietf/mn-templates-ietf/vendor/bundle/ruby/3.0.0/gems/metanorma-ietf-2.3.1/lib/asciidoctor/ietf/validate.rb:74:in `cache_workgroup'
...

Proposed solution

This can be fixed by caching ~/.metanorma-ietf-workgroup-cache.json like already done here:

One cons: this IETF specific logic and it will be in all other CI configuration

FYI @ronaldtse

Unify Makefile for all mn-samples-*

The Makefile in mn-samples-itu and mn-samples-ogc are now identical, and I've tried it for mn-samples-ietf as well. It should work for all mn-samples-*.

This task is to add the Makefile to cimas config and apply them across all mn-samples-*.

Update bundler?

We don't fail Travis builds if the latest version of Ruby fails, but the ruby head build, Travis Ruby 2.6.*, is now failing because we're using an obsolete version of Builder:

Bundler could not find compatible versions for gem "bundler":
  In Gemfile:
    bundler (~> 2.0.1)
  Current Bundler version:
    bundler (2.1.0.pre.1)
This Gemfile requires a different version of Bundler.
Perhaps you need to update Bundler by running `gem install bundler`?
Could not find gem 'bundler (~> 2.0.1)' in any of the relevant sources:
  the local ruby installation
The command "bundle update" failed and exited with 6 during .

Should we globally switch to bundler ~> 2?

xcode compilation breaking Travis metanorma-standoc

issue so far restricted to metanorma-standoc, OSX builds; other gems building fine:

Still running (12 of 20): brew install --HEAD https://raw.githubusercontent.com/metanorma/homebrew-metanorma/master/Formula/metanorma.rb
2402The command brew install --HEAD https://raw.githubusercontent.com/metanorma/homebrew-metanorma/master/Formula/metanorma.rb exited with 1.
2403
2404Log:
2405
2406Warning: Your Xcode (9.4.1) is outdated.
2407Please update to Xcode 10.1 (or delete it).
2408Xcode can be updated from the App Store.
2409
2410

....

/Users/travis/.travis/functions: line 553: 14616 Terminated: 15          travis_jigger "${!}" "${timeout}" "${cmd[@]}"
2564The command "if [[ "$TRAVIS_OS_NAME" == "osx" ]]; then travis_wait brew install --HEAD https://raw.githubusercontent.com/metanorma/homebrew-metanorma/master/Formula/metanorma.rb ; fi" failed and exited with 1 during .
2565
2566

gem install unf_ext failed on windows

https://github.com/metanorma/mn-samples-itu/pull/68/checks?check_run_id=522010507 & all mn-samples-* repos

Kind of known issue knu/ruby-unf_ext#52

I will check what we can do about this

make failed, exit code 2

Gem files will remain installed in
C:/hostedtoolcache/windows/Ruby/2.5.7/x64/lib/ruby/gems/2.5.0/gems/unf_ext-0.0.7.6
for inspection.
Results logged to
C:/hostedtoolcache/windows/Ruby/2.5.7/x64/lib/ruby/gems/2.5.0/extensions/x64-mingw32/2.5.0/unf_ext-0.0.7.6/gem_make.out

An error occurred while installing unf_ext (0.0.7.6), and Bundler cannot
continue.
Make sure that `gem install unf_ext -v '0.0.7.6' --source
'https://rubygems.org/'` succeeds before bundling.

In Gemfile:
  metanorma-cli was resolved to 1.2.10.1, which depends on
    metanorma-acme was resolved to 1.4.4, which depends on
      metanorma-standoc was resolved to 1.3.21, which depends on
        relaton-iev was resolved to 0.1.3, which depends on
          relaton was resolved to 0.10.1, which depends on
            relaton-un was resolved to 0.1.0, which depends on
              http-cookie was resolved to 1.0.3, which depends on
                domain_name was resolved to 0.5.20190701, which depends on
                  unf was resolved to 0.1.4, which depends on
                    unf_ext
make: *** [Makefile.win:109: bundle] Error 5

Repair GitHub Action build scripts for relaton-iev

The relaton-iev build scripts contain

steps:
      - uses: actions/checkout@master
      with:
          submodules: recursive

submodules is not supported in GitHub Actions, and there are not submodules in relaton-iev anyway. I could not find any instances of submodules in metanorma/metanorma-build-scripts, but just in case, please check that submodules are not being added now into any GitHub Action scripts. (This is the only instance I could find in my local copy of relaton and metanorma.) I have deleted the lines from the build scripts.

Don't fail-fast and increase concurrent jobs for matrix jobs

https://help.github.com/en/articles/workflow-syntax-for-github-actions

jobs.<job_id>.strategy.fail-fast

When set to true, GitHub cancels all in-progress jobs if any matrix job fails. Default: true

jobs.<job_id>.strategy.max-parallel

The maximum number of jobs that can run simultaneously when using a matrix job strategy. By default, GitHub will maximize the number of jobs run in parallel depending on the available runners on GitHub-hosted virtual machines.

strategy:
  max-parallel: 2

Upgrading cache action to the recent version

Hi there, Recently while I was working on the CLI then I came across an issue related to the caching gems, and I suspect this might be related to an old version for cache action. Especially even after changing the *.gemspec file, it's was using the old hash key.

I temporarily updated it to cache@v2 in the CLI and it seems to be fixing the issue for now, What do you guys think about updating the cache action version globally here?

Ref: metanorma/metanorma-cli#180

// cc: @CAMOBAP, @ronaldtse

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.