🚀 Pre-release master -> staging_TheNameless4

[mrnicegyu11]

What kind of pre-release?

master branch

Sprint Name

TheNameless

Pre-release version

4

Commit SHA

a03ed85924a9246c62926d6da362d4aee48c2197

Did the commit CI suceeded?

• The commit CI succeeded.

Motivation

Weekly staging release

What Changed

• ✨ webserver API: generate invitation #4796 by @pcrespov
• 🎨 Frontend: Replace Credits Indicator with just a Label #4795 by @odeimaiz
• 🐛 Fix flaky test (CI worker ran out of space) #4806 by @GitHK
• 🔨 Review env-vars for garbage-collector and event-listener services (⚠️ devops) #4800 by @pcrespov
• ♻️ adding option to turn on/off computation of credit computation (⚠️ OPS) #4792 by @matusdrobuliak66
• ✨ PO center: Invitations #4798 by @odeimaiz
• 🎨 New logo #4808 by @odeimaiz
• ♻️ Move db implementation from webserver/payments to packages/postgres-database #4804 by @pcrespov
• 🐛 api-server: fix bug in search files endpoint #4802 by @bisgaard-itis
• 🔨 add new helper comment to the GitHub PR template  #4813 by @matusdrobuliak66
• 🔨 fix release monitoring cli #4811 by @matusdrobuliak66
• ✨ Feature: Shared Credits notification #4809 by @odeimaiz
• ♻️ changed director-v2 env var definition in compose spec by making it explicit #4786 by @GitHK
• 🎨 Update font: Manrope #4815 by @odeimaiz
• ♻️ Minor refactor of RUT API #4803 by @pcrespov
• 🐛 Fix: Mesh viewer #4817 by @odeimaiz
• ♻️✨ refactoring of pricing plans (🗃️) #4812 by @matusdrobuliak66

Devops check ⚠️ devops

• Add changes (if any) and release tags in https://github.com/ITISFoundation/osparc-ops-environments/tags
• Add changes (if any) and release tags in osparc-ops-deployment-configuration (staging.osparc.io & osparc-staging.speag.com)
• ...

e2e testing check 🧪

No response

Summary 📝

• make release-staging name=TheNameless version=4 git_sha=a03ed85924a9246c62926d6da362d4aee48c2197
  • https://github.com/ITISFoundation/osparc-simcore/releases/new?prerelease=1&target=<commit_sha>&tag=staging_<sprint_name><version>&title=Staging%20<sprint_name><version>
• Draft pre-release
• Announce (add redis key maintenance in every concerned deployment)

{"start": "2023-10-03T11:00:00.000Z", "end": "2023-10-03T13:00:00.000Z", "reason": "Release TheNameless4"}

- [ ] Announce release in Mattermost

🔊  Maintenance scheduled for NAMED_DAY DD. MM from START_TIME - END_TIME.

@ALL Be aware that you will automatically be logged out and your projects stopped and saved during the maintenance time. Affected:

• https://staging.osparc.io
• https://https://staging.s4l-lite.io/

and on premises:

• https://osparc-staging.speag.com
• https://tip-staging.speag.com
• https://s4l-staging.speag.com
• https://s4l-lite-staging.speag.com

Reason: Scheduled staging-release of STAGING_NAME_AND_VERSION.

Thanks for your understanding and sorry for the inconveniences,

Your friendly oSparc Team

### Releasing

- [ ] Check hanging sidecars. Helper command to run in director-v2 CLI `simcore-service-director-v2 close-and-save-service <uuid>`
- [ ] Release (release draft)
- [ ] Check Release CI
- [ ] Check deployed
- [ ] aws deploy
- [ ] dalco deploy
- [ ] Delete announcement
- [ ] Check e2e runs
- [ ] Announce
``` md
https://github.com/ITISFoundation/osparc-simcore/releases/tag/staging_<sprint_name><version>

[mrnicegyu11]

Comments:

• For the first time we released using a gitlab CI/CD pipeline. In the end it worked. The pipeline is present in https://git.speag.com/oSparc/osparc-ops-deployment-configuration/-/tree/staging.osparc.io and https://git.speag.com/oSparc/osparc-ops-deployment-configuration/-/tree/osparc-staging.speag.com
• When running docker stack deploy to update existing (old) simcore services, the docker services did not fetch the latest docker images for the specified tag. This should be considered a bug and needs a fix. It was mitigated by updating the services with re-pulling docker images via portainer in this case.
• When running docker stack deploy, the webserver did at least once revert to an old state, where the docker service of the simcore-webserver did not have a necessary env-var specified for itself. It was in effect missing one env-var. Another run of docker stack deploy has fixed the problem. We are not sure about the root cause. One assumption is that the stack staging-simcore previously existed and was created through the portainer-api. Portainer then assumes that it has "full ownership" over the stack. "Updating" the stack using docker stack deploy might lead portainer to become confused about the desired state of the service. I suggest to next time before releasing running docker stack rm staging-simcore to eleminate this possibility and have the docker stack deploy command recreate the stack from scratch.
• The registry (ops-service) on aws-staging had a wrong env-var for the S3 bucket name specified. I did not manage to find out how this wrong variable comes into play. I have manually fixed the variable in portainer. Likely upon the next release to staging this might happen again, beware.

Further notes:

• I think we agreed we would not announce staging pre-releases anymore in mattermost etc., since all users for their regular work have been moved to production. So maybe these sections in the pre-release github issue template should be removed