| Age | Commit message (Collapse) | Author |
|---|
|
pipeline URL for omnibus triggers
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
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.
|
|
|
|
|
|
|
|
Enable JUnit results for rspec
See merge request gitlab-org/gitlab-ce!21449
|
|
|
|
|
|
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.
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Checks that new Ruby files will enable
frozen string literal.
Partially addresses #47424.
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Update Git version to 2.18.0
See merge request gitlab-org/gitlab-ce!20489
|
|
Add the CI Job trigger as the build trigger
Closes charts/gitlab#586
See merge request gitlab-org/gitlab-ce!20619
|
|
Trigger rails5 tests if variable is set
See merge request gitlab-org/gitlab-ce!20609
|
|
|
|
Currently the Danger processing is producing false positives when master is
merged into a branch. Until #49175 is fixed, we should allow it to fail.
|
|
For building CNG images on tag
|
|
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
Refactor the review-docs workflow
See merge request gitlab-org/gitlab-ce!20365
|
|
|
|
|
|
|
|
|
|
|
|
This was missed from
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20130
|
|
|
|
eslint has the possibility to ignore inline config `no-inline-config`, so we should use that
|
|
cloud-native triggers.
|
|
|
|
|
|
|
|
|
|
Upgrade to Ruby 2.4.4
See merge request gitlab-org/gitlab-ce!19055
|
|
|
|
Fixes that make this work:
* A change in Ruby (https://github.com/ruby/ruby/commit/ce635262f53b760284d56bb1027baebaaec175d1)
requires passing in the exact required length for OpenSSL keys and IVs.
* Ensure the secrets.yml is generated before any prepended modules are
loaded. This is done by renaming the `secret_token.rb` initializer to
`01_secret_token.rb`, which is a bit ugly but involves the least impact on
other files.
|
|
This fixes build errors caused by a stale cache since the new Docker image
upgraded from Debian Jessie to Stretch, which shipped an updated version
of OpenSSL.
|
|
|
|
Add check for top-level ee directory in CE repo
Closes #46239
See merge request gitlab-org/gitlab-ce!19062
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Improve the single-script jobs CI config
See merge request gitlab-org/gitlab-ce!19040
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
And use a supported syntax for ignoring docs during gem install
|
|
When on a tag, trigger a multi-project pipeline in the CNG repostiory.
Opting for a trigger rather than an addition to our release-tools
project for a few reasons:
- The Dockerfiles in the CNG image repo change infrequently, and as a result
I don't feel the need/overhead for stable branches in that repo at this time
- My intent with the CNG repo, is that once stable, the Dockerfiles
would actualy move to their component projects, to be versioned with the
code they are building
- It is likely that we will want to followup with a manually triggered package
for branches for devs, and possibly review apps, so it made sense to
build the CNG ci jobs to accept this sort of pipeline.
|
|
Never drop the database when granting privileges
|
