Staff

[1.9.1]

• Update Prometheus to 2.30.1
• Full changelog

[1.9.1]

• Update OnlyOffice to 6.4.1
• Full changelog

Looks like we are all good now.
I will submit a PR for the docs on gitlab for a migration step.

Hi and welcome @DigitEgal we currently do not have any further referral options available. From what you described with the custom support provided by you, are you thinking of maintaining the Cloudron instances on behalf of your users? If this is the case we have some bits already implemented to customize the support section, but this is not finished yet. We need more use-case descriptions here to finalize this.

New blocking issue about missing LDAP filter https://github.com/firefly-iii/firefly-iii/issues/5133

Ahhh finally.
I deleted the registry: part in the secrets.yaml and now runners are accessible again!

After a final testing by the owner, I will write up a doc for this type of migration.

@girish The https://DOMAIN.TLD//admin/runners return error code 500.
This should be a problem with the migrated secrets.
The secrets where a gitlab-secrets.json I converted the json to yaml.

After that I noticed that gitlab_rails should be production.
Some more testing...

@zylstra looks like that VPS was still busy installing updates on first boot, which is why the dpkg lock is still held by some other process. In such cases letting the VPS settle after first boot for some time helps until it is fully provisioned by the VPS provider.

The actual first message about the installed packages is more of an issue though. Did you happen to install anything prior to Cloudron or ran a manual server update?

@girish
The last error

2021-09-28 06:36:02 +0000 -- Restoring container registry images ... 
rake aborted!
Errno::ENOENT: No such file or directory - /app/data/backups/registry.tar.gz
/home/git/gitlab/lib/backup/files.rb:95:in `run_pipeline!'
/home/git/gitlab/lib/backup/files.rb:60:in `restore'
/home/git/gitlab/lib/tasks/gitlab/backup.rake:277:in `block (4 levels) in <top (required)>'
/home/git/gitlab/lib/tasks/gitlab/backup.rake:86:in `block (3 levels) in <top (required)>'
/home/git/gitlab/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
Tasks: TOP => gitlab:backup:registry:restore
(See full trace by running task with --trace)

But I think I can ignore this one since the old gitlab simply did not backup the registry.
Now the gitlab goes thru testing by his Owner.

@girish

App Title and Version
GitLab 14.2.3
App ID
d5499e3c-f81b-43d0-9372-4d69fa223688
Package Version
com.gitlab.cloudronapp@1.55.3
Last Updated
3 days ago

Btw. The Gitlab Version in this information is wrong, the version should be 14.2.4 since this is the version running in this release tag.
So I am running the v1.55.3
I will add gitaly_backup_path: /home/git/gitaly/gitaly-backup to backup: and try again, after a app restart.