Use self.integrity_uri over self.hexdigest_integrity_uri(digest), as the
latter always returned nil leading to improper cache invalidation.
We are alos enabling caching of `tmp/cache/assets/sprockets` again, to
get those performance gains.
By changing the `review-build-cng` job to be a `single-script-job`, the
repository content wasn't there, including the `*_VERSION` files, thus
leading to missing variables for components in the triggered pipeline.
Signed-off-by: Rémy Coutable <remy@rymai.me>
This started with
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24339 where a
broken link was introduced, but the lint checker never caught it.
The docs-lint job does the following:
```yaml
script:
- mv doc/ /tmp/gitlab-docs/content/
- cd /tmp/gitlab-docs
# Build HTML from Markdown
- bundle exec nanoc
# Check the internal links
- bundle exec nanoc check internal_links
```
It moves the `doc/` dir inside `content` where Nanoc is expecting the
markdown files to be. It then builds the site and finally checks for
the links. If the built website was deployed to production, that would
be under `docs.gitlab.com/doc`.
The interesting part here is that
`[the logs](/doc/administration/logs.md#productionlog)`
translates to `<a href="/doc/administration/logs.html#productionlog>`,
so, Nanoc correctly sees this as an existing file!
This MR changes the path of the docs content to be equal to
$DOCS_GITLAB_REPO_SUFFIX which is defined as an environment
variable and takes the value of the slug of each project:
'ce', 'ee', 'omnibus', 'runner'.
In https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20654 this job
was marked as allowing failures, but this allows developers to ignore
the results that Danger produces. Since it's not clear why the job was
allowed to fail, and since it's somewhat counter productive, we no
longer allow it to fail.
This check never worked once the global navigation changes were rolled
out in https://gitlab.com/gitlab-com/gitlab-docs/merge_requests/362. The
global nav will ALWAYS include /ce and /ee links, and the CE and EE
repos will never include documentation for both. gitlab-docs now
expects the documentation to be in the following directories:
* /tmp/gitlab-docs/ce (CE)
* /tmp/gitlab-docs/ee (EE)
* /tmp/gitlab-docs/omnibus (Omnibus)
The problem is that the CE and EE repos will only include one of the
first two.
Let's disable this check until
https://gitlab.com/gitlab-com/gitlab-docs/issues/305 is resolved.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/55038
It appears that for some jobs
(https://gitlab.com/gitlab-org/gitlab-ce/-/jobs/129705025 for example)
we process a range of commits far greater than necessary, which can lead
to commits getting reverted that were merged a long time ago.
[ci skip]
This sets up GitLab CI to automatically push CE master changes into EE
master, or revert them if the changes cause merge conflicts. The CI
configuration contains a single job to do this: `merge:master`. This job
is executed for every push to master, and periodically using a CI
schedule.
The periodic job is necessary because incremental jobs may not be able
to revert commits if newly added commits depend on these commits. By
re-running the job periodically (including all changes since a large
enough time frame), we can ensure that such commits are also reverted
(if they still conflict at that time).
The job runs in its own "merge" stage, _after_ the build and prepare
stages, but _before_ running the tests. This ensures that randomly
failing tests won't prevent code from being merged into EE. Running the
stage after the "prepare" stage reduces the chances of the job reverting
CE changes just because it ran before a corresponding EE MR was merged
into EE master.
Ordinarily it would get the `gitlab-org` tag from
`dedicated-no-docs-pull-cache-job`, but adding the `docker` tag
overwrites rather than inherits, so this job has been running on the
underpowered hardware of the shared runners rather than our dedicated
runners.
We're also adding a `high-cpu` tag, which doesn't currently do anything
but will be useful for targeting a runner specifically for this job.
CI jobs will be triggered both with rails 4 and 5
to make sure we keep backward compatibility if it turns out
we have to switch back to rails 4.
Rails 4 jobs are not allowed to fail for now, these jobs will be
removed in a follow-up MR next cycle.
Attempt to update google-protobuf for migration-paths
Because the one we were using aren't compatible with
Ruby 2.5.3, and it'll be troublesome to switch Ruby.
Upgrading google-protobuf will be much easier.
All of them will need to be updated for Ruby 2.5.3
We remove oj because we don't really need it and it
doesn't compile on 2.5.3 with that version.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/41825
In `deploy`, if the previous deployment failed, we delete/cleanup all
the objects related to the release, including secrets. The problem is
that if we create the root password before that, it will be then
recreated during the deploy with a random value!
By creatigng the secret just before actually deplying a new release, we
ensure that it won't be overriden.
Signed-off-by: Rémy Coutable <remy@rymai.me>
* Uses the same supporting code as used in EE
* Includes automated cleanup
* Install external-dns helm chart to review apps cluster if it isn't
already
* Adds variables REVIEW_APPS_AWS_SECRET_KEY and
REVIEW_APPS_AWS_ACCESS_key
* review-apps-ce uses a different cipher
This is because the CNG pipeline now relies on the assets
compiled here in the gitlab:assets:compile job (It waits
up to 30 minutes for them)
Without this change, the cloud native job was holding up
the pipeline, preventing the assets compile job from being
run.
The problem is this: when each phase starts, it checks if all jobs in earlier
phases are complete. package-and-qa is slow. As build is the first phase, if you
trigger package-and-qa before the prepare phase is finished, the entire test
phase will be blocked until package-and-qa completes, which isn't what we want.
But equally, if build came _after_ test, then package-and-qa couldn't be started
until the tests were finished. Putting it in the same stage as the tests means
we can have our cake and eat it.
Most of these validations don't apply to preparation branches and they
cause a lot of noise in the merge request. Therefore disabling danger
when the branches look like branches that could be for a preparation MR.