Skip to content

[gitlab] support nested repos in envvar patterns #7975

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

JanKoehnlein
Copy link
Contributor

Description

Support nested repos in user-scoped env var patterns.

Related Issue(s)

Fixes #2702

How to test

See #2702

Release Notes

[gitlab] user-scoped env vars can now be filtered for nested repos on Gitlab

Documentation

@roboquat roboquat added release-note team: webapp Issue belongs to the WebApp team labels Feb 2, 2022
@roboquat
Copy link
Contributor

roboquat commented Feb 2, 2022

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please ask for approval from jankoehnlein after the PR has been reviewed.

Associated issue: #2702

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@JanKoehnlein
Copy link
Contributor Author

Don't know whether we want that as we deprecate the patterns anyway.

@JanKoehnlein
Copy link
Contributor Author

JanKoehnlein commented Feb 2, 2022

/werft run

👍 started the job as gitpod-build-jk-env-vars-in-nested-github-repos.1

@jankeromnes
Copy link
Contributor

jankeromnes commented Feb 2, 2022

Agree that the repository pattern is deprecated and should go away.

However, this does seem like a risk-free short-term quality-of-life improvement, so I'd be happy to test / review / approve it, especially since the use case of "personal env var specific to a project" is not currently supported without the prefix:

Exposed in every repo Exposed in team repos Exposed in single repo
Owned by user ☑️ user-level, */* pattern ☑️ user-level, xyz/* pattern ☑️ user-level, xyz/abc pattern
Owned by team ✖️ ✖️1 ✅ project-level

We could imagine adding a new section to the Project Env Vars page to replace the broken user-level prefix:

Project "ABC" > Settings > Variables:
---

* Owned by Team (current project-level feature)
  * VAR1
  * VAR2
  * ...

* Owned by User (new feature "project-level but per user")
  * MYVAR1
  * MYVAR2
  * ...

I think this (combined with also "team-level variables") would allow us to completely retire the repo prefix, and move to this support chart:

Exposed in every repo Exposed in team repos Exposed in single repo
Owned by user ☑️ user-level (no more prefix) ✅ team-level (per user) ✅ project-level (per user)
Owned by team ✖️ ✅ team-level ✅ project-level

@codecov
Copy link

codecov bot commented Feb 2, 2022

Codecov Report

Merging #7975 (bc1b6c6) into main (1b03d7a) will increase coverage by 2.03%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff            @@
##            main    #7975      +/-   ##
=========================================
+ Coverage   8.82%   10.86%   +2.03%     
=========================================
  Files         33       18      -15     
  Lines       2380     1022    -1358     
=========================================
- Hits         210      111      -99     
+ Misses      2165      909    -1256     
+ Partials       5        2       -3     
Flag Coverage Δ
components-gitpod-cli-app 10.86% <ø> (ø)
components-local-app-app-darwin-amd64 ?
components-local-app-app-darwin-arm64 ?
components-local-app-app-linux-amd64 ?
components-local-app-app-linux-arm64 ?
components-local-app-app-windows-386 ?
components-local-app-app-windows-amd64 ?
components-local-app-app-windows-arm64 ?
installer-raw-app ?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
installer/pkg/components/ws-manager/role.go
installer/pkg/components/ws-manager/deployment.go
installer/pkg/common/ca.go
...staller/pkg/components/ws-manager/networkpolicy.go
installer/pkg/common/common.go
installer/pkg/components/ws-manager/configmap.go
installer/pkg/common/render.go
installer/pkg/common/objects.go
installer/pkg/components/ws-manager/rolebinding.go
installer/pkg/common/storage.go
... and 5 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1b03d7a...bc1b6c6. Read the comment docs.

@JanKoehnlein
Copy link
Contributor Author

JanKoehnlein commented Feb 2, 2022

/werft run with-clean-slate-deployment

👍 started the job as gitpod-build-jk-env-vars-in-nested-github-repos.2

@JanKoehnlein
Copy link
Contributor Author

Closed in favor of #7978 with a shorter branch name that doesn't crash the preview env

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-note size/XS team: webapp Issue belongs to the WebApp team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Unable to set user environment variables for GitLab repos with nested groups
3 participants