The "basename" here needs to be the full path without the trailing
extension, instead of stripping the leading path as well.
This was previously fixed in 2f36efa087 inside the view, but the
problematic code was still present in FoundBlob, and the corresponding
spec didn't actually use a child wiki page to properly verify the fix.
This commits adds support for metrics dashboards
for embedding. If the flag 'embedded' is provided
to the environments/id/metrics_dashboard endpoint,
the response will be suitable for embedding in
issues or other content.
This is a precursor for support for embedding
metrics in GFM.
Gitaly data wasn't available to the team, an this change is a first
iteration towards understanding what data we need and how to interpret
it. Later more values will be added.
For now the most important thing is the filesystem String Array, as that
includes data on ext4 exposure and NFS.
Part of: https://gitlab.com/gitlab-org/gitlab-ce/issues/60602
This adds a `markdown_field` to our types.
Using this helper will render a model's markdown field using the
existing `MarkupHelper` with the context of the GraphQL query
available to the helper.
Having the context available to the helper is needed for redacting
links to resources that the current user is not allowed to see.
Because rendering the HTML can cause queries, the complexity of a
these fields is raised by 5 above the default.
The markdown field helper can be used as follows:
```
markdown_field :note_html, null: false
```
This would generate a field that will render the markdown field `note`
of the model. This could be overridden by adding the `method:`
argument. Passing a symbol for the method name:
```
markdown_field :body_html, null: false, method: :note
```
It will have this description by default:
> The GitLab Flavored Markdown rendering of `note`
This could be overridden by passing a `description:` argument.
The type of a `markdown_field` is always `GraphQL::STRING_TYPE`.
We noticed in
https://gitlab.com/gitlab-com/gl-infra/production/issues/908 some
Bitbucket imports took over a second to load their projects row because
`import_error` was huge due to errors. To prevent this, we now:
1. Clean the backtraces
2. Log the details into importer.log
3. Omit the details from the database
So funny story, true story. I tried to run the test locally, but
didn't make it past setting up Gitaly.
Here's what I tried:
First attempt:
`git clone gitlab-ce`
`cd gitlab-ce && bundle install`
`be rspec`
This didn't work because I was missing the config/database.yml, I
didn't see a `script/bootstrap` so I looked in the readme which
redirected me to a webpage which redirected me to the
gitlab-development-kit.
Second attempt:
`gem install gitlab-development-kit`
cd gitlab-development-kit
gdk init
gdk isntall
This broke somwhere along the way because it couldn't install Gitaly
because my go version was too low. But it did clone the gitlab repo
again and this time it did have a config/database.yml.
So I tried to cd into it and `be rspec
spec/lib/gitlab/database/migration_helpers_spec.rb` which complained
about the database not being configured so I:
- Changed the socket to localhost (in the config/database.yml)
- `createdb <dev_db>` `createdb test_db`
- `be rake db:test:prepare`
Great success, it was doing things! But then failed when it came at
the Gitaly step.
Since I only want to change these three lines, at the point I gave up
and entrusted the pipeline to do its thing.
What I would have liked:
- A 'It's a Rails system, I know this' readme/docs (It's in there
somewhere just couldn't find it)
- A way to run tests without having to use Gitaly
- Not having too install all the things for a small fix (I get why'd
you want this, but to me it's overkill)
The rather cryptic:
"fk_#{Digest::SHA256.hexdigest("#{table}_#{column}_fk").first(10)}"
Was too much for emacs too handle*, since it was coming from the Rails
codebase I took their way of doing the same thing and applied it here.
I think it's easier to read and it also makes emacs render the
migration helpers pretty again.
* not true, emacs can handle anything, leave emacs alone!
From now on, only match on the annotations, instead of falling back to
legacy app label. This enables users to use the app label for other
purposes such as helm charts.
The feature flag has been introduced an was turned off by default,
now the it will default to be turned on. That change would still allow
users to turn this feature off by leveraging the Rails console by
running:
`Feature.disable("gitaly_catfile-cache")`
Another option is to manage the number of items the LRU cache will
contain, by updating the `config.toml` for Gitaly. This would be the
`catfile_cache_size`:
0dcb5c579e/config.toml.example (L27)
Closes: https://gitlab.com/gitlab-org/gitaly/issues/1712
The GitalyClient held a lot of logic which was all very tightly coupled.
In this instance the feature logic was extracted to make it do just a
little less and create a bit more focus in the GitalyClient's
responsibilies.
This moves all existing `image/services/before_script/variables`
into `default:`. This allows us to easily add a default and
top-level entries. `default`: is keep backward compatible: to
be considered to be job if `default:script:` is specified. This
behavior should be removed.
All existing `image/services/before_script/variables` are properly
handled in root context.
Previously this behaviour was only available to group
and instance-level clusters, as some project clusters
relied on Kubernetes credentials being passed through
to the runner instead of having their resources managed
by GitLab (which is not available when using JIT). These
clusters have been migrated to unmanaged, so resources
can be created on demand for the remaining managed clusters.
This backports all EE schema changes to CE, including EE migrations,
ensuring both use the same schema.
== Updated tests
A spec related to ghost and support bot users had to be modified to make
it pass. The spec in question assumes that the "support_bot" column
exists when defining the spec. In the single codebase setup this is not
the case, as the column is backported in a later migration. Any attempt
to use a different schema version or use of "around" blocks to
conditionally disable specs won't help, as reverting the backport
migration would also drop the "support_bot" column. Removing the
"support_bot" tests entirely appears to be the only solution.
We also need to update some foreign key tests now that we have
backported the EE columns. Fortunately, these changes are very minor.
== Backporting migrations
This commit moves EE specific migrations (except those for the Geo
tracking database) and related files to CE, and also removes any traces
of the ee/db directory.
Some migrations had to be modified or removed, as they no longer work
with the schema being backported. These migrations were all quite old,
so we opted for removing them where modifying them would take too much
time and effort.
Some old migrations were modified in EE, while also existing in CE. In
these cases we took the EE code, and in one case removed them entirely.
It's not worth spending time trying to merge these changes somehow as we
plan to remove old migrations around the release of 12.0, see
https://gitlab.com/gitlab-org/gitlab-ce/issues/59177 for more details.
Stan Hu
Kamil Trzciński
Ash McKenzie
Jan Provaznik
Thong Kuah
Douglas Barbosa Alexandre
Markus Koller
drew cimino
Sarah Yasonik
Zeger-Jan van de Weg
Sean McGivern
Bob Van Landuyt
Luke Duncalfe
Lin Jen-Shin
Adam Hegyi
pjaspers
Filipa Lacerda
Manoj MJ
Philippe Lafoucrière
Kartikey Tanna
Douwe Maan
Grzegorz Bizon
Tiger
Matija Čupić
Fabio Pitino
raju249
Yorick Peterse