# Julia and Gitlab self-hosted : a state-of-the-art?

**URL:** <https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685>\
**Category:** General Usage\
**Tags:** packages, gitlab, registry\
**Created:** [September 2, 2022, 11:54am UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685 "2022-09-02T11:54:59Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![BambOoxX](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bambooxx/32/22179_2.png) [@BambOoxX](https://discourse.julialang.org/u/BambOoxX)\
**Post date:** [September 2, 2022, 11:54am UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/1 "2022-09-02T11:54:59Z")

</div>

I have been working since last year with julia, and I developed several packages for internal use in my company. Up to now, these developments were my own and did not require much input from other developers. I am mostly versioning them using git repos on a NAS and created a private registry on that same NAS using [`LocalRegistry.jl`](https://github.com/GunnarFarneback/LocalRegistry.jl) (many thanks @GunnarFarneback ).

Since these developments tend to be used and developed by a growing amount of my colleagues, I would like to transfer the repos to a self-hosted Gitlab server, in order to benefit from all its functionalities (it did not seem worth the trouble at the beginning of my julian life).

I tried to find information on how to best take advantage of a Gitlab for Julia but either I do not have the correct keywords, or there is nothing much at the moment. The only thing that seems relevant and detailed is [GitLab-examples / julia · GitLab](https://gitlab.com/gitlab-examples/julia)

So if it was not already answered before, could people share their experience on the difficulties related to Gitlab CI / CD with Julia, e.g with :

- Migration from a local storage
- Registry setup
- Test pipeline
- Documentation pipeline

---

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [September 2, 2022, 12:27pm UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/2 "2022-09-02T12:27:09Z")

</div>

Invenia has like everything setup on gitlab for our internal stuff.  
From autoscaling CI, to documentation hosting, to code coverage hosting.  
Automatic tagging and releases when you merge.

I will poke our devs in the direction of this thread.  
I know some parts are [TagBotGitlab](https://github.com/invenia/TagBotGitLab) and LocalRegistry.jl

---

<div class="post-metadata">

**Author:** ![jd-foster](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jd-foster/32/35824_2.png) [@jd-foster](https://discourse.julialang.org/u/jd-foster)\
**Post date:** [September 3, 2022, 7:36am UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/3 "2022-09-03T07:36:51Z")

</div>

Recent thread:

> [@Package on gitlab not github](https://discourse.julialang.org/t/package-on-gitlab-not-github/86637/2):
>
> Hi Gitlab is perfectly fine to use for Julia packages, and so is any other git host. Github is used as the most common example because it is the most popular one and widely used within the Julia community (for better or worse), but it’s not necessary to use it. PkgTemplates.jl has a Github Actions plugin, but right next to it you can see that it also has a [GitLab CI](https://invenia.github.io/PkgTemplates.jl/stable/user/#PkgTemplates.GitLabCI) (for handling continuous integration tasks when using Gitlab). In the main Template call, you can see for the user keyword, it …

---

<div class="post-metadata">

**Author:** ![BambOoxX](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bambooxx/32/22179_2.png) [@BambOoxX](https://discourse.julialang.org/u/BambOoxX)\
**Post date:** [September 6, 2022, 2:49pm UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/4 "2022-09-06T14:49:58Z")

</div>

Thanks ! It seems that `PkgTemplates` defines a lot of stuff to help create new packages will all the configuration baked-in. However, I have the feeling that this requires configuration at a higher level than package (e.g. registry …), and that seems out of the scope of `PkgTemplates`, is it ?

---

<div class="post-metadata">

**Author:** ![ArnaudHenry](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/arnaudhenry/32/42494_2.png) [@ArnaudHenry](https://discourse.julialang.org/u/ArnaudHenry)\
**Post date:** [September 6, 2022, 3:55pm UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/5 "2022-09-06T15:55:40Z")

</div>

Hey, I’m a dev at Invenia (co-worker of @oxinabox), and this is an overview of our CI setup.

- Test pipeline

Every Julia package we have lives in its own GitLab repo. Each has a .gitlab-ci.yml file which defines the pipeline for that repo.  
The one you linked to is a good starting point [.gitlab-ci.yml · master · GitLab-examples / julia · GitLab](https://gitlab.com/gitlab-examples/julia/-/blob/master/.gitlab-ci.yml).  
The basic idea for the test job is to use a julia docker image, clone the repo and run Pkg.test.  
Like in that example, you can have one job per julia version you want to support.  
If you have many packages like we have at invenia, you may want to have a central yml file somewhere (we have this live in its own separate repo) which defines a standard pipeline, and then have all package repos `include` that file.

We run tests on all packages every night to see if updated dependencies break our code (they get updated according to the semver we specify in our Project.toml files).  
We do this with a scheduled pipeline on each repo.

Now to get the tests to actually run you need to set up some machines with the Gitlab Runner installed. We do this on a Mac mini which we have setup in our office, and also on AWS, where we have an AutoScalingGroup that scales the number of machines up and down based on CPU usage. We test on different architectures, and do that with the use of GitLab CI tags. Can provide more details if needed.

- Documentation pipeline

Documentation is simply another job in the standard pipeline.  
Actually, unlike the example you pointed to, we split it into two jobs.  
“Documentation” builds the documentation (for every run of the pipeline, including for merge requests, so that we can review the doc changes before we approve and merge things), and “pages” publishes the docs (only on the default branch).  
Here’s roughly what the .gitlab-ci.yml looks like for those jobs (untested, copy pasted and simplified stuff from different files, as our setup has complexified over the years):

```julia
"Documentation":
  artifacts:
    paths:
      - documentation/
  script:
    julia --project=docs/ -e "using Pkg; Pkg.instantiate()"
    julia --project=docs/ docs/make.jl
    # Move the rendered documentation to a folder called "documentation" in the root of
    # the repo which will be saved in an artifact.
    mkdir documentation
    mv docs/build/* documentation/

# Use the special job name "pages" to actually trigger deployment of the documentation on master.
# https://docs.gitlab.com/ee/user/project/pages/getting_started_part_four.html#job
pages:
  only:
    variables:
      # Only deploy docs on the default branch (eg master)
      - $CI_DEFAULT_BRANCH == $CI_COMMIT_REF_NAME
  dependencies:
    - Documentation
  artifacts:
    # As documentation is re-deployed every night the expiry just ensures that old documentation
    # is eventually cleaned up.
    expire_in: 1 week
    paths:
      - public/ # Note: Required to be called public for GitLab Pages
  script:
    - mkdir public
    - '[-d documentation] && mv documentation/* public/'

```

- Registry setup

We have a `PackageRegistry` repo, which is a private equivalent of the Julia General registry, with just our private packages in it.  
(Not sure how this was setup initially).  
Users should install this registry on their local machine in addition to the general one (replace with your URL / name):

```julia
git clone <your_registry_repo> ~/.julia/registries/<company_name>

```

All julia package repos have a “Register” job which runs LocalRegistry.jl `register` on it: (again untested, copy pasted from different places)

```julia
“Register”:
  rules:
    # Attempt registration when Project.toml changes in the default branch
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      changes:
      - "Project.toml"
  script:
    # Set git config so the commits to the registry are from a given GitLab user
    - git config --global user.email "<email>"
    - git config --global user.name "<username>"
   # Register
    - julia -e 'using Pkg; Pkg.add(name="LocalRegistry", version="0.5.2")'
    - julia --project -e "using LocalRegistry; register(<local_package_path>, registry = \"<your_registry_repo>\", repo = \"$CI_PROJECT_URL\", create_gitlab_mr = true)"

```

(Special thanks to @gunnarfarneback for implementing the `create_gitlab_mr` functionality after we raised an issue!)

This will create a merge request in the PackageRegistry to add/update the julia package.  
The PackageRegistry repo has its own .gitlab-ci.yml pipeline which runs the RegistryCI tests:

```julia
“​​Registry Tests":
  script:
    - julia --project=.ci/ -e 'using Pkg; Pkg.instantiate()'
    - julia --project=.ci/ --color=yes -e 'using RegistryCI; RegistryCI.test(registry_deps=["https://github.com/JuliaRegistries/General.git"])'

```

Once the tests pass, you can merge that MR, and from that point the new package/version will be available to users.  
Note we automate the merge using [GitHub - invenia/TagBotGitLab: Julia TagBot for GitLab](https://github.com/invenia/TagBotGitLab) which we run in an AWS Lambda (this also creates the GitLab git tags and release notes for each package). There might be simpler ways to automate the merge.

- Migration from a local storage

We haven’t done this so can’t attest to it. But I think it is mostly about creating projects in Gitlab (1 project = 1 repo) and uploading & changing remote for your git repos (including the private registry).

So that’s the basics of it. A CI setup can be as complex as you need it to be (and ours has definitely become more complex over the years, to account for our many use cases). Happy to share more or answer specific questions. We’re thinking of putting out some blog posts on this topic, but it might take us a while to do that.

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [September 7, 2022, 8:09am UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/6 "2022-09-07T08:09:45Z")

</div>

The setup at my company is less complex and correspondingly less ambitious in most, but not all, aspects.

- Packages

Normally one per GitLab project (i.e. repository). Some projects contain dual Julia and Python packages, making use of the Pkg subdir functionality to point to the `julia` subdirectory. One project contains three closely related Julia packages.

If you have existing packages in git repositories elsewhere they are easily imported to GitLab. All git services have excellent instructions for how to import git repositories from anywhere else.

- Testing

We run tests for all new commits (including merge requests and after merging to master) but no periodical tests of unchanged code. All tests are run in docker containers, either built from a Dockerfile in the repository or using a stock docker image from a common CI project. The typical test job is

```julia
test julia:
  stage: test
  script:
    - julia --project=julia -e 'using Pkg; Pkg.test()'

```

(This is an example from a dual package, so the Julia package is in the `julia` directory. The docker image is implicit from a `default` directive.)

- Documentation

Most packages are documented by the `README` and additional markdown files in the repository. Some projects use an in-house documentation system which converts markdown files and various data sources to PDF files. This is just another CI job and the built PDFs are exported as CI artifacts.

- Registry

The registry is just another repository. If you already have one on disk you can import to GitLab like any other repository. You should only need to update the `repo` field in the `Package.toml` for each package.  
CI runs for all commits and basically consists of calling `RegistryCI.test`.

- Registration

All julia packages use a common registration job, included from the common CI project, like this:

```julia
stages:
  - julia registration

include:
  project: $ci_project
  file:
    - templates/julia_package_registration.yml

variables:
  julia_package_dir: julia

```

The template is somewhat complex:

```julia
variables:
  Registry: https://project_71_bot:$JULIA_REGISTRATOR_TOKEN@$URL_TO_REGISTRY
  julia_package_dir: .
  package_repo_git_url: "git@$GITLAB_URL:$CI_PROJECT_PATH.git"

julia package registration:
  stage: julia registration
  only:
    - master
  script:
    - git config --global user.name $GITLAB_USER_NAME
    - git config --global user.email $GITLAB_USER_EMAIL
    - julia -e 'using Pkg; Pkg.add("LocalRegistry")'
    - cd $julia_package_dir
    - julia -e "using LocalRegistry; register(registry = \"$Registry\", repo = \"$package_repo_git_url\", create_gitlab_mr = true, ignore_reregistration = true)"

```

This uses an access token (the `project_71_bot:$JULIA_REGISTRATOR_TOKEN` stuff) to obtain credentials for the registry project and is run on every commit to master (but not on merge requests). If the version number has not been bumped, the `LocalRegistry.register` call won’t do anything. Merge requests for the registry are created by the `create_gitlab_mr` option and as soon as the registry CI job has passed they are automatically merged and immediately available.

- Package Server

Packages are distributed using an in-house package server driven by the [LocalPackageServer](https://github.com/GunnarFarneback/LocalPackageServer.jl) package. This means that the users have to set the environment variable `JULIA_PKG_SERVER` to point to this package server but they don’t have to add the company registry by URL, and they don’t need to have or bother with credentials for the GitLab server.

---

<div class="post-metadata">

**Author:** ![BambOoxX](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bambooxx/32/22179_2.png) [@BambOoxX](https://discourse.julialang.org/u/BambOoxX)\
**Post date:** [September 7, 2022, 1:57pm UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/7 "2022-09-07T13:57:46Z")

</div>

Thanks @ArnaudHenry and @GunnarFarneback for all the precious info.

So to sum up:

- At the registry level

- At the package level

Some points are still unclear to me though your answers are already a lot:

- @GunnarFarneback Is a package server required ? So far I’m just installing the registry on my pc and everything works fine.
- @ArnaudHenry Are all the CI jobs done with a julia docker image ? How do you configure that part (sorry if it’s too much to ask)
- @ArnaudHenry You developed `TagBotGitlab` with python, is it because [GitHub - JuliaComputing/GitLab.jl](https://github.com/JuliaComputing/GitLab.jl) is not developed ? Wouldn’t it be more straightforward to use that (if it were more advanced) ?

Anyway thanks again for all these tips, now I have to get into digesting this and test it on my setup !

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [September 7, 2022, 2:16pm UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/8 "2022-09-07T14:16:27Z")

</div>

> [@BambOoxX](#):
>
> The registry should have a CI test job using `RegistryCI.test` in order to verify its integrity any time a package or a new version of a package is registered.

It’s a sound thing to do but to be honest I’ve never seen it fail. Then again, should I happen to introduce a bad enough bug in LocalRegistry, you may save time from detecting it early.

> [@BambOoxX](#):
>
> @GunnarFarneback Is a package server required ? So far I’m just installing the registry on my pc and everything works fine.

Not at all, it’s just a quality of life improvement if your organization struggles with GitLab credentials or have less technically inclined users who find adding a registry URL with Julia’s package manager to be an obscure thing to do.

Additionally it lets you cache packages and artifacts inside your internal network, which may or may not be an interesting feature.

---

<div class="post-metadata">

**Author:** ![BambOoxX](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bambooxx/32/22179_2.png) [@BambOoxX](https://discourse.julialang.org/u/BambOoxX)\
**Post date:** [September 7, 2022, 2:35pm UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/9 "2022-09-07T14:35:40Z")

</div>

> [@GunnarFarneback](#):
>
> Not at all, it’s just a quality of life improvement if your organization struggles with GitLab credentials or have less technically inclined users who find adding a registry URL with Julia’s package manager to be an obscure thing to do.

Assuming the registry to be public (inside my organization) could the package server bypass the Gitlab safeties, e.g. if a user does not have access to a package repo, could he install it through the package server ? That looks like some sort of a backdoor if it’s the case ^^.

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [September 7, 2022, 2:50pm UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/10 "2022-09-07T14:50:43Z")

</div>

> [@BambOoxX](#):
>
> Assuming the registry to be public (inside my organization) could the package server bypass the Gitlab safeties, e.g. if a user does not have access to a package repo, could he install it through the package server ? That looks like some sort of a backdoor if it’s the case ^^.

If you have people inside your organization who shouldn’t be allowed read-only access to the Julia package code, you either shouldn’t have a package server or set up that as well with some kind of credentials for access.

If all people can be trusted with that access and your security model is fine with exposing code openly on the internal network, it’s rather a feature not having to deal with keys or tokens when you install Julia packages (whether it’s for users or in CI scripts).

---

<div class="post-metadata">

**Author:** ![DrPapa](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/drpapa/32/6835_2.png) [@DrPapa](https://discourse.julialang.org/u/DrPapa)\
**Post date:** [September 8, 2022, 8:10pm UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/11 "2022-09-08T20:10:29Z")

</div>

My solution was to make a `JuliaPkgs` group where every user has at least read access. All registered packages are in this group.

---

<div class="post-metadata">

**Author:** ![Barget](https://avatars.discourse-cdn.com/v4/letter/b/94ad74/32.png) [@Barget](https://discourse.julialang.org/u/Barget)\
**Post date:** [September 9, 2022, 12:56pm UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/12 "2022-09-09T12:56:58Z")

</div>

Thanks @ArnaudHenry for the detailed explanation and your work at Invenia. I’ve been using `PkgTemplates.jl` at my company recently and it has provent to be very useful.

Actually, I think this explanation - which is very good - could be almost published “as is” in julia Forem, don’t you think?

Providing with all relevant information in one place about how to implement a proper Julia CI/CD would surely help spreading its use in companies. I’ve found myself struggling a bit to gather all the relevant bits to do so.

BTW, thanks also @GunnarFarneback for `LocalRegistry.jl`, which was very usefull too.

---

<div class="post-metadata">

**Author:** ![ArnaudHenry](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/arnaudhenry/32/42494_2.png) [@ArnaudHenry](https://discourse.julialang.org/u/ArnaudHenry)\
**Post date:** [September 20, 2022, 9:34am UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/13 "2022-09-20T09:34:14Z")

</div>

Sorry for the late reply. Note I wasn’t there when all this was setup, so doing a bit of digging / learning myself 🙂

> Are all the CI jobs done with a julia docker image ? How do you configure that part

Yes we try to use docker jobs as much as possible.  
Our docker jobs run on an image we build ourselves, based off `amazonlinux:2` and where we install julia and other utilities like aws cli, and also git clone our private `PackageRegistry` into it.

> You developed TagBotGitlab with python, is it because GitHub - JuliaComputing/GitLab.jl is not developed ? Wouldn’t it be more straightforward to use that (if it were more advanced) ?

I think TagBotGitlab was meant as a clone of [GitHub - JuliaRegistries/TagBot: Creates tags, releases, and changelogs for your Julia packages when they're registered](https://github.com/JuliaRegistries/TagBot) (written in Python), but for GitLab. We also used to have an internal web server running [GitHub - JuliaRegistries/Registrator.jl: Julia package registration bot](https://github.com/JuliaRegistries/Registrator.jl), before we switched to using `LocalRegistry.jl` instead.

I think TagBot and Registrator.jl are well-suited for the open source GitHub community and the General Julia registry, however probably a bit too complex for an internal setup (notably having to deploy them as separate lambda / web server).

GitLab.jl doesn’t seem maintained, however [GitHub - JuliaWeb/GitForge.jl: Unified interface for interacting with Git forges](https://github.com/JuliaWeb/GitForge.jl) would likely be a good alternative.

---

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [September 20, 2022, 11:09am UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/14 "2022-09-20T11:09:58Z")

</div>

> [@BambOoxX](#):
>
> @ArnaudHenry You developed `TagBotGitlab` with python, is it because [GitHub - JuliaComputing/GitLab.jl](https://github.com/JuliaComputing/GitLab.jl) is not developed ? Wouldn’t it be more straightforward to use that (if it were more advanced) ?

My recollection of the history there was that at some point (possibly still now) this ran inside a AWS Lambda.  
Which at the time it was written didn’t support Julia.

---

<div class="post-metadata">

**Author:** ![e3c6](https://avatars.discourse-cdn.com/v4/letter/e/e79b87/32.png) [@e3c6](https://discourse.julialang.org/u/e3c6)\
**Post date:** [September 20, 2022, 11:35am UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/15 "2022-09-20T11:35:11Z")

</div>

Hi, do you have any comments on how to deal with possible Dependency Confusion attacks?

> <https://github.com/JuliaLang/Pkg.jl/issues/2393>
>
> \[A recent, novel supply chain attack\](https://medium.com/@alex.birsan/dependency…-confusion-4a5d60fec610) on some package managers is also possible in certain Pkg/Registry configurations.
> 
> The gist of it is that some package managers, when given a package name, by default look in "internal" repos first, then also check the "public" repos and install whichever returns a higher version number. For this attack to be successful in Pkg, the attacker would also have to know the UUID of the internal package and register a package in General with both the same name and the same UUID, but a higher version number (e.g. 9001.0.0). Once registered, Pkg installs whichever version is higher, thereby allowing "shadowing" of the internal package with a malicious package.
> 
> A MWE can be found at https://github.com/DilumAluthge/MWE\_multiple\_registries\_same\_package\_uuid.
> 
> The intention for all possible fixes is to preserve the ability to have multiple registries available to provide the same package. This should not allow attackers to intentionally register packages with the same name & UUID as another package in a different registry and mislead people into downloading their malicious package.
> 
> \-----
> 
> A non-breaking fix is for each private registry user who also uses General to use the 3 day waiting period to monitor for clashes in new package registrations to General. This should be automatable with some tooling, which comments on the PR to General and thus stops the automerge. As a precaution, private registry users may want to create new UUIDs for their internal packages and investigate how the UUID leaked in the first place.
> 
> Another non-breaking fix on a registry-per-registry basis would be to mirror & vet General manually, though this is somewhat high maintenance and thus unlikely to be useful in practice. This would also require some investigation into how the UUID leaked, should a mismatch be detected.
> 
> A possible long-term fix would involve a new \`shadowable\` entry in \`Package.toml\`, which would be opt-in and signal that the package is allowed to come from other registries as well. In this model, all installed registries that have the same combination of \`(name, UUID)\` would also need to have \`shadowable=true\` set for that package. If any registry doesn't have this set, we error.
> 
> This would be a breaking change, so our options are:
> 1. Do it in Julia 2.0.
> 2. Do it in Julia 1.x, but make a lot of Slack posts and Discourse posts informing people of the change, and make it easy for people (JC, Invenia, Beacon, etc) to make the changes needed. This would only affect local/internal registries that have shared a package with other registries (e.g. by open sourcing them to General). We should work closely with those who are known to have opensourced packages to make their transition as easy as possible.

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [September 20, 2022, 11:54am UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/16 "2022-09-20T11:54:21Z")

</div>

Until better tooling arrives in Pkg, my only advice is not to expose your internal package UUIDs to the external world.

If your registry is public, see [Dependency confusion between internal registries and General · Issue #2393 · JuliaLang/Pkg.jl · GitHub](https://github.com/JuliaLang/Pkg.jl/issues/2393#issuecomment-1093951501).

---

<div class="post-metadata">

**Author:** ![BambOoxX](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bambooxx/32/22179_2.png) [@BambOoxX](https://discourse.julialang.org/u/BambOoxX)\
**Post date:** [October 3, 2022, 9:01am UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/17 "2022-10-03T09:01:22Z")

</div>

@ArnaudHenry@GunnarFarneback I managed to used your great advice ! Each package has been moved to a separate repo on the Gitlab, as well as the registry. However, I am not sure what to do about the artifacts. They may be of different kind (some binaries that I do not compile myself, raw data …) and may be used by one or more packages.

At the moment I am thinking about two options :

1. Create an artifact repo using Git-LFS

2. Put each artifact in the first package’s wiki that uses them

- Easy, but very manual
- Not centralized, if the package is dropped at some point the artifact is lost
- No tracking of modifications (at least not in an obvious manner to me)

Would you have an advice how to best do that ?

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [October 3, 2022, 9:39am UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/18 "2022-10-03T09:39:24Z")

</div>

I haven’t had a need for local artifacts so far, or at least not a big enough need to actually implement something, but I’m somewhat doubtful I would use GitLab for that at all. How to handle them would depend a lot on their nature; how big they are, where they come from, etc.

---

<div class="post-metadata">

**Author:** ![BambOoxX](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bambooxx/32/22179_2.png) [@BambOoxX](https://discourse.julialang.org/u/BambOoxX)\
**Post date:** [October 3, 2022, 11:50am UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/19 "2022-10-03T11:50:40Z")

</div>

> [@GunnarFarneback](#):
>
> or at least not a big enough need to actually implement something

Do you mean that you do not use artifacts at all, or that you simply put them with the rest of your packages ?

At the moment, I’m working on a NAS, and this works just fine, except for the user rights which requires an admin to give access. With GitLab, I figured one could have more flexibility in that regard, but I may be mistaken.

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [October 3, 2022, 12:42pm UTC](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685/20 "2022-10-03T12:42:09Z")

</div>

Obviously we use artifacts with packages from the General registry but we haven’t needed artifacts for our own packages. For what it’s worth many of them were developed before artifacts even existed.

[Next page](https://discourse.julialang.org/t/julia-and-gitlab-self-hosted-a-state-of-the-art/86685.md?page=2)