| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/54862
|
|
|
|
|
| |
This reverts commit 1e8f1de034aa9b6a60b640b2b091f60c4d3ba365, reversing
changes made to 62d971129da99936a3cdc04f3740d26f16a0c7a6.
|
|\
| |
| |
| |
| |
| |
| | |
Allow internal references to be removed
Closes #19376
See merge request gitlab-org/gitlab-ce!23189
|
| | |
|
|/ |
|
| |
|
|\
| |
| |
| |
| | |
Expose merge request pipeline variables
See merge request gitlab-org/gitlab-ce!23398
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Introduce the following variables
- CI_MERGE_REQUEST_ID
- CI_MERGE_REQUEST_IID
- CI_MERGE_REQUEST_REF_PATH
- CI_MERGE_REQUEST_PROJECT_ID
- CI_MERGE_REQUEST_PROJECT_PATH
- CI_MERGE_REQUEST_PROJECT_URL
- CI_MERGE_REQUEST_TARGET_BRANCH_NAME
- CI_MERGE_REQUEST_SOURCE_PROJECT_ID
- CI_MERGE_REQUEST_SOURCE_PROJECT_PATH
- CI_MERGE_REQUEST_SOURCE_PROJECT_URL
- CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
|
| |
| |
| |
| | |
permissions but permissions are not overridden"
|
|\ \
| |/
|/|
| |
| |
| |
| | |
Encrypt CI/CD builds tokens
Closes #52342
See merge request gitlab-org/gitlab-ce!23436
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
Use group clusters when deploying (DeploymentPlatform)
See merge request gitlab-org/gitlab-ce!22308
|
| | |
| | |
| | |
| | |
| | |
| | | |
This also means we need to apply the `current_scope` otherwise this
method will return all clusters associated with the groups regardless of
any scopes applied to this method
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
With this MR, group clusters is now functional, so default to enabled.
Have a single setting on the root ancestor group to enabled or disable
group clusters feature as a whole
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Rename ordered_group_clusters_for_project ->
ancestor_clusters_for_clusterable
- Improve name of order option. It makes much more sense to have `hierarchy_order: :asc`
and `hierarchy_order: :desc`
- Allow ancestor_clusters_for_clusterable for group
- Re-use code already present in Project
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
AFAIK the only relevant place is Projects::CreateService, this gets
called when user creates a new project, forks a new project and does
those things via the api.
Also create k8s namespace for new group hierarchy
when transferring project between groups
Uses new Refresh service to create k8s namespaces
- Ensure we use Cluster#cluster_project
If a project has multiple clusters (EE), using Project#cluster_project
is not guaranteed to return the cluster_project for this cluster. So
switch to using Cluster#cluster_project - at this stage a cluster can
only have 1 cluster_project.
Also, remove rescue so that sidekiq can retry
|
| | |
| | |
| | |
| | |
| | | |
For project level, it's the project directly associated. For group
level, it's the projects under that group.
|
| | |
| | |
| | |
| | |
| | | |
This returns a union of the project level clusters and group level
clusters associated with this project.
|
| | |
| | |
| | |
| | |
| | | |
kubernetes_namespaces is not needed for project import/export as it
tracks internal state of kubernetes integration
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Look for matching clusters starting from the closest ancestor, then go
up the ancestor tree.
Then use Ruby to get clusters for each group in order. Not that
efficient, considering we will doing up to `NUMBER_OF_ANCESTORS_ALLOWED`
number of queries, but it's a finite number
Explicitly order query by depth
This allows us to control ordering explicitly and also to reverse the
order which is useful to allow us to be consistent with
Clusters::Cluster.on_environment (EE) which does reverse ordering.
Puts querying group clusters behind Feature Flag. Just in case we have
issues with performance, we can easily disable this
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Improve help and validation sections of maximum build timeout inputs
Closes #49434
See merge request gitlab-org/gitlab-ce!23586
|
| | |/
| |/| |
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Merge request pipelines
See merge request gitlab-org/gitlab-ce!23217
|
| | | | |
|
| | |/
| |/| |
|
|\ \ \
| |_|/
|/| |
| | |
| | | |
Extract code into IssueBoardEntity / serializer (follow up)
See merge request gitlab-org/gitlab-ce!23511
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Use a 32-byte version of db_key_base for web hooks
Closes #53659
See merge request gitlab-org/gitlab-ce!23573
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
AES-256-GCM cipher mode requires a key that is exactly 32 bytes long.
We already handle the case when the key is too long, by truncating, but
the key can also be too short in some installations. Switching to a key
that is always exactly the right length (by virtue of right-padding
ASCII 0 characters) allows encryption to proceed, without breaking
backward compatibility.
When the key is too short, encryption fails with an `ArgumentError`,
causing the web hooks functionality to be unusable. As a result, zero
rows can exist with values encrypted with the too-short key.
When the key is too long, it is silently truncated. In this case, the
key is unchanged, so values encrypted with the new too-long key will
still be successfully decrypted.
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Make KUBECONFIG nil if KUBE_TOKEN is nil
See merge request gitlab-org/gitlab-ce!23414
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Having an invalid KUBECONFIG without a token in it is not helpful. This
only became possible recently now that we are creating a separate
namespace and service account (and hence token) to send to the runners.
This led to somewhat surprising results when troubleshooting
https://gitlab.com/gitlab-org/gitlab-ce/issues/53879 as I found that the
KUBECONFIG was still being passed but KUBE_TOKEN was not. These things
really should have been linked.
Furthermore now that we are also using the [presence of KUBECONFIG to
decide whether or not to run build steps in Auto
DevOps](https://gitlab.com/gitlab-org/gitlab-ce/blob/294d15be3e9497e7b67e1f9131ce9d5c0d68406c/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml#L164)
I think it makes even more sense to ensure that KUBECONFIG is a complete
config if passed to a job.
|
| |/ /
|/| |
| | |
| | |
| | | |
For CE, #lfs_http_url_to_repo calls #http_url_to_repo where as for EE we
examine for a Geo setup so we can support push to secondary for LFS.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Encrypt runners tokens
Closes #51232 and #52931
See merge request gitlab-org/gitlab-ce!23412
|
| | | | |
|
| |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
fix/gb/encrypt-runners-tokens
* commit '83f0798e7dc588f0e4cb6816daadeef7dbfc8b81': (101 commits)
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
fix/gb/encrypt-runners-tokens
* commit '6852680584a1b22788f451457a6042eabf862a73': (57 commits)
|
| |\ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
* master: (243 commits)
Conflicts:
db/schema.rb
lib/gitlab/import_export/import_export.yml
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|