Auto-DevOps.gitlab-ci.yml

@nolith @ayufan Since we want to kill Auto Deploy and replace it with Auto DevOps in 10.0, we may as well work in the final target location.

mentioned in merge request !80 (closed)

changed the description

minimal-ruby-app fails test because Unable to select a buildpack. This isn't a problem during build because we provide a Dockerfile. For some reason adding a .buildpack didn't help, but setting a project variable for BUILDPACK_URL did. Unfortunately, the ruby buildpack requires a Gemfile.lock, which the minimal ruby app doesn't have, so testing still fails. Not sure if there's any way forward with that other than using a more standard app. But I wonder how common this kind of problem is going to be for people, and thus an annoyance with suddenly tons of people getting false failure alerts.

Tried with our template Node app and build worked, until it tried to push docker image and then:

Configuring registry.gitlab.com/markpundsack/express: docker image...
invalid reference format

The above is because of the REGISTRY_TAG @nolith already pointed out. Only hitting it now because the Node app doesn't have a Dockerfile so it's actually using Herokuish.

changed the description

Fixing the above gets the build to work, but then test fails with Unable to select a buildpack, which is strange considering the build step was able to select a buildpack. I'm guessing @dzaporozhets's test image is somehow missing the standard buildpacks. No, it's got a /bin/herokuish buildpack install in the Dockerfile.

Ugh, buildpack problem was a stupid mistake. It's late. I'm going to bed.

But not until testing one more time...

test succeeds now, but strangely, it probably shouldn't.

...
-----> Build succeeded!

> demo@0.0.0 test /app
> echo 'Error: no test specified'

Error: no test specified
Job succeeded

Not sure how that error doesn't resolve as a failure.

I'm having trouble deploying the node project as a review app. Getting access forbidden. But not going to debug further tonight.

@markpundsack regarding herokuishing minimal-ruby-app I use this nolith/minimal-ruby-app@65d8743d1ef0697f1beec6bf7fdc11569b6f5c23

I think that the changes in ruby.rb can be ported to master, bacause Dockerfile declares PORT, but in general we may need to keep this as a minimal-reby-hearouish-app fork due to the lack of Dockerfile.

@nolith Thanks. I think we can leave the Dockerfile in there as Auto DevOps will use it. We'll have to see the impact on build duration as the original app was incredibly fast.

Side note: we should figure out how to cache for buildpacks.

@markpundsack is https://gitlab.com/gitlab-org/gitlab-ci-yml/merge_requests/88#note_38380691 still relevant?

@dzaporozhets no, that comment isn't relevant anymore. I still wonder about the next comment where the job succeeds even when the command fails because of no tests. Have you tested that command failure exit codes are passed properly?

I haven't had a chance to test actual test failures.

@markpundsack I tested test exists & pass vs test exists & broken. Success gives 0, fail gives 1:

Failure

dzaporozhets:~/Projects/ruyb-sinatra-zero-config-ci dz-try-zero-ci-2 
→  docker run --rm -v "$(pwd):/tmp/app" registry.gitlab.com/gitlab-org/herokuish /bin/herokuish buildpack test
-----> Ruby app detected
-----> Setting up Test for Ruby/Rack
-----> Using Ruby version: ruby-2.3.3
-----> Detecting rake tasks
-----> Running test: bundle exec rspec
       .F
       Failures:
       1) Sum should eq 5
       Failure/Error: it { expect(2+4).to eq(5) }
       expected: 5
       got: 6
       (compared using ==)
       # ./spec/sum_spec.rb:3:in `block (2 levels) in <top (required)>'
       Finished in 0.01146 seconds (files took 0.06964 seconds to load)
       2 examples, 1 failure
       Failed examples:
       rspec ./spec/sum_spec.rb:3 # Sum should eq 5

dzaporozhets:~/Projects/ruyb-sinatra-zero-config-ci dz-try-zero-ci-2 
→ echo $?
1

Success

→  docker run --rm -v "$(pwd):/tmp/app" registry.gitlab.com/gitlab-org/herokuish /bin/herokuish buildpack test
-----> Ruby app detected
-----> Setting up Test for Ruby/Rack
-----> Using Ruby version: ruby-2.3.3
-----> Detecting rake tasks
-----> Running test: bundle exec rspec
       ..
       Finished in 0.00266 seconds (files took 0.06918 seconds to load)
       2 examples, 0 failures

dzaporozhets:~/Projects/ruyb-sinatra-zero-config-ci dz-try-zero-ci-2 
→ echo $?
0

Cool, thanks.

changed the description

https://gitlab.com/charts/charts.gitlab.io/merge_requests/52 fixed the access forbidden problem! Wish I had seen it earlier.

changed the description

marked the checklist item topic branch as completed

marked the checklist item merge to master as completed

changed the description

DOCKER_DRIVER: overlay2 worked for me on GitLab.com runners, so I made the switch. To be tested on k8s.

I was experimenting with setting the number of replicas, but it's failing sh parsing, so I've commented it out for now. Would love @nolith to take a look.

My test projects are in: https://gitlab.com/dockersaurus

BTW, I think the rails template should use Postgres. https://gitlab.com/gitlab-org/gitlab-ce/issues/37156

I'm running this script inside a k8s cluster (like I2P sales demo) and from gitlab.org shared runners.

For minimal-ruby-app we need to merge gitlab-examples/minimal-ruby-app!3 not sure who is maintaining it. ( maybe @markpundsack ? )

I've tested automated production deploy, codequality, review app.

414e6ab8 will be a bit redundant once gitlab-ce!13849 will be merged, but helps at the momend in understanding why jobs are failing.

mentioned in merge request gitlab-examples/minimal-ruby-app!3

I've fixed auto-test, now it runs well on k8s and shared runners.

I've started testing on nolith/rails-hello-world@a19aae77b47f1f1c50f1f75f2550836d3d67f774...31ce35a2431082add32909cd89ed42f89963b8ca based on @dzaporozhets work.

It can build, test and code-climate but fails on deployment. I think there's a problem with our helm chart and the deployed pod enter a crash-loop because of missing DATABASE_URL. @ayufan maybe you can help me on this.

marked the checklist item merge to master as incomplete

I tried running it on the Java Spring template, and got:

$ eval "$ENSURE_NAMESPACE"
The connection to the server localhost:8080 was refused - did you specify the right host or port?
error: name must be specified

I retried once, and got the same thing. I'm really not sure why.

@markpundsack maybe you are missing the kubernetes integration?

@nolith Ugh, yes, that's exactly it. Noob mistake. :)

For now, maybe CHECK_KUBE_DOMAIN should check that too. :)

@markpundsack @ayufan @bikebilly I was able to test review app with rails on k8s.

All I needed was a working controller on / nolith/rails-hello-world@9b0e612b

@bikebilly yes. when I say review app I mean "forking, merge request, testing review app, merging to master, checking new production, checking stopped environments"

We need to do something about Tiller not being ready even when deploy says successful.

Tiller (the helm server side component) has been installed into your Kubernetes Cluster.
Happy Helming!
Waiting for rollout to finish: 0 of 1 updated replicas are available...
deployment "tiller-deploy" successfully rolled out
Client: &version.Version{SemVer:"v2.5.0", GitCommit:"012cb0ac1a1b2f888144ef5a67b8dab6c2d45be6", GitTreeState:"clean"}
[debug] context deadline exceeded
Error: cannot connect to Tiller
Failed to init Tiller.
ERROR: Job failed: exit code 1

Retrying again got:

$ eval "$INSTALL_TILLER"
Checking Tiller...
$HELM_HOME has been configured at /root/.helm.
Warning: Tiller is already installed in the cluster.
(Use --client-only to suppress this message, or --upgrade to upgrade Tiller to the current version.)
Happy Helming!
Unable to connect to the server: dial tcp 104.197.176.182:443: i/o timeout
ERROR: Job failed: exit code 1

before finally working, on the forth try. Well, I should say that Tiller worked on the 4th try. The deploy still failed waiting for the readiness probe.

@nolith I don't understand why the Rails template (or any rails new) doesn't have a working controller on /.

@nolith https://gitlab.com/nolith I don't understand why the Rails template (or any rails new) doesn't have a working controller on /.

In the early rails days they used to ship a default public/index.html, the only purpose of such file was explaining how to remove it. It has been removed since rails 4

https://github.com/rails/rails/blob/3-2-stable/railties/lib/rails/generators/rails/app/templates/public/index.html

With the last commit also uncomment staging, canary, and production's when: manual works.

Still no support for replicas

@markpundsack @bikebilly replicas are working now.

Given the shell escaping hell @ayufan suggested me to move from eval to multiline scripts. This greatly enhances readability and reusability.

Unlikely this introduced incoherent behaviors in our template.

If someone wants to try it the template at 14e82fd6 is a good version.

Scripts are easier to grok. Are you thinking of converting all evals like this?

Yes @markpundsack it's easier for us and for the users IMHO.

I think that we must clear the variables section completely and leave there only things we want the user to change eventually, like POSTGRES_*.

I've completed the conversion to shell scripting.

@ayufan can you review it please?

the kubernetes: true part is commented out otherwise the linting will fail.

assigned to @ayufan

@nolith Overall, I like this version much better. It's more readable and makes logical sense. One downside is the use of before_script which means developers can't make use of before_script anywhere else, without losing Auto DevOps. If we're going to go that way, you could even skip the .auto_devops declaration and just put it all in the before_script. But I guess leaving it there means I could define a job's before_script to include .auto_devops and something custom.

@markpundsack regarding before_script I decided to use

before_script:
  - *auto_devops

so that users can add their own lines after - *autodevops but also if they want to customize only a specific job they can easily import autodevops before their own stuff.

@markpundsack @bikebilly @ayufan I'm removing the WIP status.

Before going live we need to merge https://gitlab.com/charts/charts.gitlab.io/merge_requests/63 otherwise AutoDevops will break once we upgrade our auto-deploy-app chart.

Test is failing because of gitlab.com CI linter not knowing about kubernetes: active

unmarked as a Work In Progress

mentioned in merge request !87 (closed)

regarding before_script I decided to use

before_script:

*auto_devops

> so that users can add their own lines after `- *autodevops` but also if they want to customize only a specific job they can easily import autodevops before their own stuff.

@nolith I totally understand why you did it, and can't think of anything better. It's just unfortunate to use global `before_script` at all as it's fairly common for someone to edit a job and add their own `before_script` without realize they're overriding the template's usage of `before_script`. Once they realize what they've done, it's easy to fix.

Ideally we'd make it clear that the global `before_script` is set by putting it higher in the `.gitlab-ci.yml` file. Basically everything after the `-------` line is likely to be ignored. But we can't move the `before_script` higher because YAML depends on the YAML template being defined before it is used.

When we have `include` capability, we can put the include at the top, which will define all the YAML templates, and then the global `before_script` can be right at the top and transparent.

The only alternative today is to explicitly define `before_script` for each job. It's more transparent, but also ugly. Although, it would also allow us to move some of the other `script` content into the `before_script` sections.

e.g.:

build: stage: build image: docker:git services:

docker:dind variables: DOCKER_DRIVER: overlay2 before_script:
- load_autodevops_functions
- setup_docker script:
- build only:
- branches


At any rate, we don't need to make any changes for 10.0. I just wanted my logic out there so it's clear as we iterate.

resolved all discussions

merged

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/34833.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/33266.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/32826.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/30723

mentioned in issue #32

Admin message

Admin message

Auto-DevOps.gitlab-ci.yml

Merge request reports

Activity

Failure

Success