オンプレGitLabでgit+CI+npmサーバー2024 の履歴(No.10)

目次†

全体としての注意†

上記のようにして動かすと、etc/ フォルダに etc/gitlab.rb というのができて、 これを書き換えれば設定を変えられる。

設定項目についてはこちらに説明がある。
https://gitlab-docs.creationline.com/omnibus/settings/configuration.html

また、ファイルの冒頭には以下の注意書きがある。

## GitLab configuration settings
##! This file is generated during initial installation and **is not** modified
##! during upgrades.
##! Check out the latest version of this file to know about the different
##! settings that can be configured, when they were introduced and why:
##! https://gitlab.com/gitlab-org/omnibus-gitlab/blame/master/files/gitlab-config-template/gitlab.rb.template
 
##! Locally, the complete template corresponding to the installed version can be found at:
##! /opt/gitlab/etc/gitlab.rb.template
 
##! You can run `gitlab-ctl diff-config` to compare the contents of the current gitlab.rb with
##! the gitlab.rb.template from the currently running version.
 
##! You can run `gitlab-ctl show-config` to display the configuration that will be generated by
##! running `gitlab-ctl reconfigure`
 
##! In general, the values specified here should reflect what the default value of the attribute will be.
##! There are instances where this behavior is not possible or desired. For example, when providing passwords,
##! or connecting to third party services.
##! In those instances, we endeavour to provide an example configuration.
 
## GitLab URL
##! URL on which GitLab will be reachable.
##! For more details on configuring external_url see:
##! https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-the-external-url-for-gitlab
##!
##! Note: During installation/upgrades, the value of the environment variable
##! EXTERNAL_URL will be used to populate/replace this value.
##! On AWS EC2 instances, we also attempt to fetch the public hostname/IP
##! address from AWS. For more details, see:
##! https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html
# external_url 'GENERATED_EXTERNAL_URL'
 
## Roles for multi-instance GitLab
##! The default is to have no roles enabled, which results in GitLab running as an all-in-one instance.
##! Options:
##!   redis_sentinel_role redis_master_role redis_replica_role geo_primary_role geo_secondary_role
##!   postgres_role consul_role application_role monitoring_role
##! For more details on each role, see:
##! https://docs.gitlab.com/omnibus/roles/index.html#roles
##!
# roles ['redis_sentinel_role', 'redis_master_role']
 
## Legend
##! The following notations at the beginning of each line may be used to
##! differentiate between components of this file and to easily select them using
##! a regex.
##! ## Titles, subtitles etc
##! ##! More information - Description, Docs, Links, Issues etc.
##! Configuration settings have a single # followed by a single space at the
##! beginning; Remove them to enable the setting.
 
##! **Configuration settings below are optional.**

一方、例えば data/nginx/conf/gitlab-http.conf に nginx 関連の設定ファイルが見つかるのだけれど、 こちらの設定ファイルはサーバーを立ち上げ直すと gitlab.rb の内容を元に自動的に生成されるものなので、 手で書きかえてはいけない。

ちゃんと冒頭に

# This file is managed by gitlab-ctl. Manual changes will be
# erased! To change the contents below, edit /etc/gitlab/gitlab.rb
# and run `sudo gitlab-ctl reconfigure`.

などと書かれている。

etc/gitlab.rb を書き換えてしまうと設定情報が docker-compose.yml と gitlab.rb とに分かれてしまうので、どちらか一方にまとめた方がいいのかもしれない。

単純な見やすさからすると docker-compose.yml に書く方が良さそうなのだけれど、 gitlab-ctl diff-config を使うなら gitlab.rb でもいいのかもしれない。

docker コンテナの外から確認するなら：

LANG:console
$ docker compose exec web gitlab-ctl diff-config

ポートの指定†

外からの接続を受ける apache2 と同じマシンに置くのであれば docker-compose.yml の

     ports:
       - '8980:80'

のところは

     ports:
       - '127.0.0.1:8980:80'

として、外からの接続が直接 docker へ行かないようにする。

docker でポートを開けると ufw などのファイアウォールで許可してなくても 外向きにポートが開いてしまうので十分注意する。

https を名乗りつつ http で待ち受ける†

gitlab の設定で

      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://myserver.com/gitlab'
        nginx['listen_port'] = 80
        nginx['listen_https'] = false

としている理由は以下の通り。

この docker イメージは external_url の設定を見て、内部の nginx で 80 番で http を待つか、443 番で https を待つかを決めている。

「どちらか片方しか有効にならない」というのが重要な点。

今実現したい構成では、外部から見た gitlab サーバーのアドレスは https://myserver.com/gitlab で https 接続になるのだけれど、その暗号化通信は間に入る apache2 が受け持つので docker 内の nginx への接続は http になる。

external_url を https としてしまうと gitlab docker は nginx を 443 番で https を待つように設定してしまい 80 番の http では繋がらなくなってしまう。

そこで 80 番で http を待つように設定しているのがこの部分だ。

サーバーに繋ぎに行って「接続をリセットされました」みたいになるときは、

LANG:console
$ sudo less data/nginx/conf/gitlab-http.conf

として gitlab 関連の nginx の設定を確かめるといい。

(これに気付くのにかなり時間がかかりました・・・)

GITLAB_OMNIBUS_CONFIG で指定可能なその他の設定†

GITLAB_OMNIBUS_CONFIG では

LANG:console
$ sudo less etc/gitlab.rb 

として表示される設定項目に値を指定できるので、 「こんなことできないのかな」と思ったときにはじっくり読むといい。

普段使いのユーザーを作っておく†

この root ユーザーを使って普段使いのユーザー（以下では "myname" とする）を作っておく。

自分で変更した root のパスワードを忘れてしまった場合†

root のパスワードを自分で変更して、その後忘れてしまうと困ったことになる。

そんな時は、

https://blog.k-bushi.com/post/tech/environment/construct-gitlab-runner-docker/#gitlab%E3%81%B8%E3%81%AE%E3%83%AD%E3%82%B0%E3%82%A4%E3%83%B3

にあるように、

LANG:console
$ docker compose exec web gitlab-rake "gitlab:password:reset"
Enter username: root
Enter password: 
Confirm password: 
Password successfully updated for user with username root.

とすればパスワードを設定しなおせるらしい。

GitLab 画面で新しい Runner インスタンスを作成†

https://myserver.com/gitlab/admin/runners

から右上の [New Instance Runner] を押す。

ここでは特別な設定をしないごく一般的な shell の動くサーバーを建てるので、

x Run untagged jobs のチェックを付けて [Create runner] とする。

docker で動かした Runner と対応付ける†

次の画面の Step 1 となっているところで

$ gitlab-runner register
   --url https://myserver.com/gitlab
   --token glrt-iqghvxb-GLHJG9WsFPT6

のようなところをコピーする。

ちょっと手直しをして次の形にして Runnner を起動した docker-compose.yml のあるフォルダで実行。

$ docker compose exec runner \
   gitlab-runner register \
       --url https://myserver.com/gitlab \
       --token glrt-iqghvxb-GLHJG9WsFPT6

コマンドを起動するといくつか質問に答えることになる。

• GitLab instance URL には指定した https://myserver.com/gitlab が入っているのでそのまま ENTER
• Enter a name for the runner にはこの Runner を識別する名前を付ける
• Enter an executor には shell を指定

これで Runner 一覧に正しく追加される。

ERROR: Verifying runner... failed → extra_hosts の設定が必要？†

何らかの事情で Runner の docker 内部から myserver.com で apache2 の動くサーバーへ到達できない場合には（LAN 内で ローカル IP を持っている場合など）、

$ docker compose exec runner \
   gitlab-runner register \
       --url https://myserver.com/gitlab \
       --token glrt-iqghvxb-GLHJG9WsFPT6
                                                   
Enter the GitLab instance URL (for example, https://gitlab.com/):
[https://myserver.com/gitlab]: <ENTER>

ERROR: Verifying runner... failed                   runner=yFiGd5DTA status=couldn't execute POST against https://myserver.com/gitlab/api/v4/runners/verify: Post "https://myserver.com/gitlab/api/v4/runners/verify": dial tcp xx.xx.xx.xx:443: connect: connection refused
PANIC: Failed to verify the runner.            

のように connection refused というエラーが出て失敗する。

このときは docker-compose.yml 内で runner に

    extra_hosts:
      - myserver.com:192.168.0.2

のようなのを追加して https://myserver.com/gitlab でサーバーへ到達できるようにしておく必要がある。

CI スクリプトの書き方†

概要：
https://gitlab-docs.creationline.com/ee/ci/yaml/gitlab_ci_yaml.html

リファレンス：
https://gitlab-docs.creationline.com/ee/ci/yaml/index.html

用語の整理：

• パイプラインは複数のステージから構成される
• 個々のステージは並列実行可能な複数のジョブから構成される
• 個々のステージは前のステージのジョブがすべて成功してから次へ進む

node 環境を準備＆ビルド＆テスト†

例えば、以下の .gitlab_ci.yml と package.json をコミットしてみる。

.gitlab_ci.yml

variables:
 NODE_VERSION: 22
 NVM_VERSION: v0.40.0

stages:
  - build
  - test
  - package

cache:
  paths:
    - dist/*

# common setting for each job
default:
  before_script:
    - ls -d "$HOME/.nvm" || (curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/${NVM_VERSION}/install.sh | bash)
    - export NVM_DIR="$HOME/.nvm"
    - \[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
    - nvm --version
    - nvm use ${NODE_VERSION} || nvm install ${NODE_VERSION}

# each job is associated to a stage
build:
  stage: build
  script:
    - echo $CI_PIPELINE_SOURCE
    - echo $CI_COMMIT_REF_NAME
    - echo $CI_COMMIT_TAG
    - echo $CI_COMMIT_BRANCH
    - npm run lint
    - npm run build
  environment: production

test:
  stage: test
  script:
    - npm run test:unit --run
 
package:
  stage: package
  only:
    - tags
  except:
    - branches
  script:
    - ls dist
  artifacts:
    name: mypackage-${CI_COMMIT_TAG}.tar.gz
    paths:
      - dist/*

package.json

LANG:console
{
        "name": "mypackage",
        "version": "0.0.1",
        "scripts": {
                "lint": "echo 'lint - success!'",
                "build": "mkdir -p dist && (echo 'Hello!' > dist/hello.txt) && echo 'build - success!'",
                "test:unit": "echo 'test:unit - success!'"
        }
}

すると build と test に成功して、

build の結果：

LANG:console
Running with gitlab-runner 17.3.1 (66269445)
  on bee01 t2X9wkLjw, system ID: r_FoHQflE05Zou
Preparing the "shell" executor 00:00
Using Shell (bash) executor...
Preparing environment 00:00
Running on 8163caea6de5...
Getting source from Git repository 00:00
Fetching changes with git depth set to 20...
Reinitialized existing Git repository in /home/gitlab-runner/builds/t2X9wkLjw/0/gitlab/osamu/gitlab-ci-hello/.git/
Checking out 504e92af as detached HEAD (ref is master)...
Skipping Git submodules setup
Executing "step_script" stage of the job script 00:07
$ ls -d "$HOME/.nvm" || (curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/${NVM_VERSION}/install.sh | bash)
ls: cannot access '/home/gitlab-runner/.nvm': No such file or directory
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 16555  100 16555    0     0  59336      0 --:--:-- --:--:-- --:--:-- 59336
=> Downloading nvm from git to '/home/gitlab-runner/.nvm'
=> Cloning into '/home/gitlab-runner/.nvm'...
* (HEAD detached at FETCH_HEAD)
  master
=> Compressing and cleaning up git repository
=> Profile not found. Tried ~/.bashrc, ~/.bash_profile, ~/.zprofile, ~/.zshrc, and ~/.profile.
=> Create one of them and run this script again
   OR
=> Append the following lines to the correct file yourself:
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
=> Installing Node.js version 22
Downloading and installing node v22.8.0...
Downloading https://nodejs.org/dist/v22.8.0/node-v22.8.0-linux-x64.tar.gz...
######################################################################## 100.0%
Computing checksum with sha256sum
Checksums matched!
Now using node v22.8.0 (npm v10.8.2)
Creating default alias: default -> 22 (-> v22.8.0 *)
=> Node.js version 22 has been successfully installed
=> Close and reopen your terminal to start using nvm or run the following to use it now:
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
$ export NVM_DIR="$HOME/.nvm"
$ \[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
$ nvm --version
0.40.0
$ nvm use ${NODE_VERSION} || nvm install ${NODE_VERSION}
Now using node v22.8.0 (npm v10.8.2)
$ npm run lint
> mypackage@0.0.1 lint
> echo 'lint - success!'
lint - success!
$ npm run build
> mypackage@0.0.1 build
> mkdir -p dist && (echo 'Hello!' > dist/hello.txt) && echo 'build - success!'
build - success!
Cleaning up project directory and file based variables 00:00
Job succeeded

test の結果:

LANG:console
Running with gitlab-runner 17.3.1 (66269445)
  on bee01 t2X9wkLjw, system ID: r_FoHQflE05Zou
Preparing the "shell" executor 00:00
Using Shell (bash) executor...
Preparing environment 00:00
Running on 8163caea6de5...
Getting source from Git repository 00:01
Fetching changes with git depth set to 20...
Reinitialized existing Git repository in /home/gitlab-runner/builds/t2X9wkLjw/0/gitlab/osamu/gitlab-ci-hello/.git/
Checking out ae25c69e as detached HEAD (ref is master)...
Removing dist/
Skipping Git submodules setup
Executing "step_script" stage of the job script 00:00
$ ls -d "$HOME/.nvm" || (curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/${NVM_VERSION}/install.sh | bash)
/home/gitlab-runner/.nvm
$ export NVM_DIR="$HOME/.nvm"
$ \[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
$ nvm --version
0.40.0
$ nvm use ${NODE_VERSION} || nvm install ${NODE_VERSION}
Now using node v22.8.0 (npm v10.8.2)
$ npm run test:unit --run
> mypackage@0.0.1 test:unit
> echo 'test:unit - success!'
test:unit - success!
Cleaning up project directory and file based variables 00:00
Job succeeded

となる。

ちゃんと初回に node がインストールされて、２回目はそれが再利用されている。

ちゃんと test をするときは report を作成するといいらしい
https://docs.gitlab.com/17.3/ee/ci/testing/unit_test_reports.html

パッケージング†

まず、上で

cache:
  paths:
    - dist/*

をしておかないと build で作成したファイルが package に引き継がれないので注意が必要だ。

そして package ステージには

  only:
    - tags
  except:
    - branches

がついているので、tag を付けたときで、なおかつそのタグがデフォルトブランチ（ここでは master）についてないとスクリプトは実行されない。

• https://stackoverflow.com/questions/42796018/how-to-run-a-gitlab-ci-yml-job-only-on-a-tagged-branch
• https://stackoverflow.com/questions/69199614/ci-commit-tag-in-if-statemets-of-regular-job

あたりを参照。

試してみよう

GitLab 画面のプロジェクトページの左上 "+" のドロップダウンから New Tag を選んで、

https://myserver.com/gitlab/myname/mypackage/-/tags/new

から 0.0.1 というタグを作成する。

・・・ん？ 新しいパイプラインが生成されないような？？？

https://forum.gitlab.com/t/pipeline-not-executed-after-commit/87173/6

によると GitLab と Runner のバージョンを合わせた方がいいと書かれてる？

GitLab のバージョンは、

$ docker compose exec web gitlab-rake gitlab:env:info

とするか、GitLab 画面左下の Help ボタンを押すことで確認できる。

ここでは 17.3.1 だった。

Runner のバージョンは GitLab の admin メニューから CI/CD - Runners で

https://myserver.com/gitlab/admin/runners

ここから個々の Runner をクリックして show detail すると、、、17.3.1 なので問題なし。

ああ、違った。

ちゃんと動いているけれど、トップ画面の緑色のチェックマークはあくまでコミットに対する CI/CD の結果で、タグに対する CI/CD の結果は Tags のページでタグの横に現れるのか。

個別のタグのページに CI/CD の結果を表示してくれないので混乱した。

https://myserver.com/gitlab/myname/gitlab-ci-hello/-/tags/0.0.1

パイプラインがすべて正しく実行されると、

https://myserver.com/gitlab/myname/gitlab-ci-hello/-/tags

のタグの横に緑のチェックが出て、その右のダウンロードメニューに artifact - package が現れる。

選択すると mypackage-0.0.1.tar.gz を落とせた。

メニュー自体の表示を mypackage-0.0.1.tar.gz にすることはできないのかな？？？

TODO: リリース時にこのアーティファクトを参照する方法も調べる

extra_hosts を設定する†

上で runner に extra_hosts を追加している場合には、

runner/config.toml にも、

[[runners]]
  [runners.docker]
    extra_hosts = ["myserver.com:192.168.0.2"]

の設定をしないと、runner docker 内部で作成される docker コンテナに hosts の設定が引き継がれないことに注意が必要。

試してみる†

これで始めから npm や playwright の使える環境で ci スクリプトを走らせることができるようになったはず。

上のスクリプトの before_script をバージョン確認だけにしてみた。

default:
  before_script:
    - node --version
    - npm --version

すると、

LANG:console
$ node --version
v20.16.0
$ npm --version
10.8.1

と表示され、残りのスクリプトも正しく実行された。

GitHub のプロジェクトをクローンして GitLab へ登録する†

まず、こちらで作った typescript-vitest-skeleton という GitHub プロジェクトをクローンして、 GitLab へ登録しなおす

https://dora.bk.tsukuba.ac.jp/~takeuchi/?typescript+%2B+vitest+%E3%81%A7+npm+%E3%83%91%E3%83%83%E3%82%B1%E3%83%BC%E3%82%B8%E3%81%AE%E9%96%8B%E7%99%BA+2024

GitLab 上で typescript-vitest-skeleton という空のプロジェクトを作成しておいて、

LANG:console
$ git clone https://github.com/osamutake/typescript-vitest-skeleton.git
Cloning into 'typescript-vitest-skeleton'...
$ cd typescript-vitest-skeleton/
$ npm i
$ git remote add origin2 https://myserver.com/gitlab/myname/typescript-vitest-skeleton.git
$ git push origin2 --all

左のメニューの Deploy - Package Registray からこの GitLab プロジェクトのパッケージレジストリを確認できる。

https://myserver.com/gitlab/myname/typescript-vitest-skeleton/-/packages

当然今は空だ。

ここに上記 npm パッケージを登録したい。

パッケージ名のスコープ†

GitLab プロジェクトのパッケージレジストリへパッケージを登録するには、

https://myserver.com/gitlab/api/v4/projects/(project id)/packages/npm/@(scope_name)/(package_name)

のようなアドレスへパッケージを PUT することになる。

ここで、

• project id : この GitLab サーバーのプロジェクトにつけられた通し番号
  • プロジェクトのトップページ https://myserver.com/gitlab/myname/typescript-vitest-skeleton の右上の縦に３つ並んだ点のアイコン（More actions）をクリックして "Copy Project ID: 9" をクリックするとコピーできる

• scope_name : npm ではパッケージ名の前に @ユーザー名 を付けることでスコープ付きにして、他のパッケージと名前が被らないようにしますが、それと似たような識別子
  • GitLab で使うときは GitLab サーバーを識別するために使うことになるみたい？

• package_name : 例えば上の typescript-vitest-skeleton

まだよくわかっていないのだけれど、どうやら GitLab の提供する npm パッケージサーバーからパッケージをダウンロードさせたい場合「"@osamu_takeuchi/*" のように @osamu_takeuchi というスコープがついているパッケージは npm ではなく特定の GitLab サーバーを探しに行け」という設定をすることになるみたいなので、パッケージ名を例えば @myserver/typescript-vitest-skeleton というような、分かりやすいスコープ付きにしておくのが良さそう？

→ これ、まるっきり間違いではないけれど、正解とは言えない理解だったことが下で明らかに。。。

LANG:console
$ git remote remove origin
$ git remote remove origin2
$ git remote add origin https://myserver.com/gitlab/myname/typescript-vitest-skeleton.git
$ sed -i.bak s/@osamu_takeuchi/@myserver/ package.json 
$ git add package.json
$ git commit -m "Scope of package is changed"
$ git push origin

デプロイ用のトークンを発行して .npmrc を設定する†

パッケージのアップロードには個々のプロジェクトからのアクセス許可が必要なので、

プロジェクトの Settings - Repository - Deploy Tokens - Add token からトークンを発行する。

https://myserver.com/gitlab/myname/typescript-vitest-skeleton/-/settings/repository

GitLab はいろんなところでいろんな用途のトークンを発行できるので、 違うところで違う用途のトークンを発行して設定して、動かないなあ、となることが多い（汗

• Name を npm push とする
• write_package_registry にチェックを入れる
• [Create deploy token] を押す
• 次の画面で gldt-XXXXXXXXXXXXXXXX のようなトークンをコピーする

プロジェクトのフォルダーにこのトークンを指定した .npmrc を作成する。

LANG:console
$ echo ".npmrc" >> .gitignore
$ cat <<"EOS" >.npmrc
//myserver.com/gitlab/api/v4/projects/9/packages/npm/:_authToken=gldt-XXXXXXXXXXXXXXXXX
@myserver:registry=https://myserver.com/gitlab/api/v4/projects/9/packages/npm/
EOS

このファイルを GitLab へアップロードしてしまうと誰でもデプロイできるようになってしまうので、 必ず .gitignore に追加しておく必要がある。

後日追記 ＞ どうやらそうではなく、

LANG:console
$ cat <<"EOS" >.npmrc
//myserver.com/gitlab/api/v4/projects/9/packages/npm/:_authToken=${NPM_TOKEN}
@myserver:registry=https://myserver.com/gitlab/api/v4/projects/9/packages/npm/
EOS

としておいて、npm publish する際に

LANG:console
$ NPM_TOKEN=gldt-XXXXXXXXXXXXXXXXX npm publish

あるいは .env に NPM_TOKEN=gldt-XXXXXXXXXXXXXXXXX を書いておいて、

LANG:console
$ dotenv npm publish

のようにした方が使いやすいみたいだ。これなら .npmrc を git でコミットして問題ない。

その際、Deploy Token ではなく下で作成する Personal Access Token でもデプロイできるようだったので、それで足りるならわざわざ Deploy Token を作る必要はないのかもしれない。

手動でデプロイする†

後は普通に（あるいは必要に応じて dotenv 付きで） npm publish すればいい。

LANG:console
$ npm publish
npm notice Publishing to https://myserver.com/gitlab/api/v4/projects/9/packages/npm/ with tag latest and default access
+ @myserver/mypackage@0.0.1

これでパッケージがデプロイされ、Package Registry に

@myserver/mypackage (latest)
0.0.1 npm

のような項目が現れる。

CI スクリプトからの自動デプロイとの兼ね合いや、上記以外の設定を .npmrc に書きたい場合があることなどを考慮すると、

• .npmrc に直接 Token を書き込むのではなく実行時に NPM_TOKEN を読ませる方が良い
• .env に保存しておいて dotenv 付きで npm publish すれば手軽

なので、今後はそのようにする。

グループを作成してプロジェクトをグループへ移す†

• Admin メニューから Private グループ myserver を作成
  • 本当は mygroup としたいところだけれど上で @myserver/mypackage という名前にしてしまっているのでそれと合わせた
• typescript-vitest-skeleton プロジェクトの Settigs - General - Advanced - Transfer Project - Select a new namespace - myserver として [Transfer project]

これで https://myserver.com/gitlab/api/v4/packages/npm/@myserver/mypackage へアクセスしたところ、正しくパッケージにアクセスできた。

しかし

LANG:console
$ npm i @myserver/mypackage
npm error 404 Not Found - GET https://registry.npmjs.org/@myserver%2fmypackage - Not found
npm error 404
npm error 404  '@myserver/mypackage@*' is not in this registry.
npm error 404
npm error 404 Note that you can also install from a
npm error 404 tarball, folder, http url, or git url.

となるのは変わらない。

問題は、

https://registry.npmjs.org/@myserver/mypackage

ではなく

https://registry.npmjs.org/@myserver%2fmypackage

へリダイレクトされていること。

なぜか / がエンコードされてしまっていて、そのせいで見つからない。

.npmrc の参照先をフロントの myserver.com ではなく、 GitLab docker の http://localhost:8980/gitlab/... に変更すると繋がるので、 この問題は間に入っている apache2 のプロキシにあると思われるのだけれど、 書き込み時に問題にならないのに読み出し時に問題になるのはなぜ？？？

フロントの apache2 のログ：

GET /gitlab/api/v4/packages/npm/@myserver%2fmypackage

GitLab docker 内の nginx のログ：

GET /gitlab/api/v4/packages/npm/@myserver%252fmypackage

あちゃあ、これは。。。

https://yomon.hatenablog.com/entry/2017/10/20/222331

この記事に答えがありました。

apache2 はそのまま受け渡そうとしているのに mod_proxy が変換してくれやがってくださっているので（ママ）、ProxyPass の最後に nocanon を付けなさいと。

    ProxyPass /gitlab http://localhost:8980/gitlab

を、

    ProxyPass /gitlab http://localhost:8980/gitlab nocanon

ですね。

これで問題なくインストールできるようになりました。

うーむ・・・遠いなあ。

まとめると、サーバーレベルのリポジトリで npm パッケージを配布する場合には、

• GitLab に最低１つのグループを作る
• npm を配布するプロジェクトは必ずいずれかのグループに入れる
• 配布する npm パッケージ名につけるスコープ (@scope/name のようなパッケージ名の / より前の部分) はGitLab プロジェクトの属するグループ名（サブグループに属する場合にはトップのグループ名）に合わせる

が必要、ということになる。

でもこれだと、せっかくサーバーレベルでリポジトリを公開したとしても、 結局 .npmrc にはスコープごとの設定が必要で、なんだか大きなメリットを感じにくい？？？

スコープはグループのリポジトリに結びつけることもできる。

# グループ番号が 12 の場合の .npmrc の設定
@myserver:registry=https://myserver.com/gitlab/api/v4/groups/12/-/packages/npm/
@mygroup:registry=https://myserver.com/gitlab/api/v4/groups/12/-/packages/npm/
@myscope1:registry=https://myserver.com/gitlab/api/v4/groups/12/-/packages/npm/
@myscope2:registry=https://myserver.com/gitlab/api/v4/groups/12/-/packages/npm/

この場合には必ずしもスコープ名とグループ名を一致させる必要はないそうなので大幅に自由度が上がる。 いろんなスコープを１つのグループに結びつけておけばやりたい放題だ(?)

グループ内にその名前のパッケージがあればそれを返し、 もしなければ npmjs.org に飛ばしてくれることを考えると、

registry=https://myserver.com/gitlab/api/v4/groups/12/-/packages/npm/

のようにデフォルトのリポジトリをここにしてしまうというのも手なのかも。

その形であれば、公開されてる npm パッケージにパッチを当てたものをここに置いて差し替えて使ったりもできるわけだし。

そういう使い方なら、見つからないときに npmjs.org に飛ばしてくれるのは良しあしという気もする。

registry= の設定を上から探して、見つかったものを使う、みたいな動作を npm がしてくれる方がさらに便利だ。

npm 自体がそういう設計にはなっていないということなのかな。（未検証）