gocd/gocd

GoCD (https://gocd.org) - Chat room for Contributors. See http://bit.ly/1mAA3RV Q&As.

daliaezt

@daliaezt

Hi All,

We tried to upgrade GoCD from 20.4 to 20.7, on 20.4 GoCD setup we are using business continuity addon.

After the upgrade, the primary GoCD started and working fine however the secondary one failed to start with below errors

2020-10-04 18:36:25,387 INFO [WrapperJarAppMain] DatabaseMigrator:40 - Upgrading database, this might take a while depending on the size of the database.
2020-10-04 18:36:25,388 INFO [WrapperJarAppMain] DatabaseMigrator:49 - **
2020-10-04 18:36:25,388 INFO [WrapperJarAppMain] DatabaseMigrator:49 - WARNING: Shutting down your server at this point will lead to a database corruption. Please wait until the database upgrade completes.
2020-10-04 18:36:25,389 INFO [WrapperJarAppMain] DatabaseMigrator:49 - **
2020-10-04 18:36:28,571 ERROR [WrapperJarAppMain] DatabaseMigrator:65 - Unable to create database upgrade script for database. The problem was: liquibase.exception.DatabaseException: Error executing SQL UPDATE public.databasechangeloglock: ERROR: cannot execute UPDATE in a read-only transaction

**We have already removed business continuity addon jar file before we start both servers on version 20.7 as it was already mentioned in documentation that this feature has been incorporated into GoCD core.

Any suggestions ?

Anderson Reyes

@AndersonReyes

so we just upgraded to version 20.8.0 and for some reason the k8s elastic agents are failing to register with the server:
r 1m. Error:
jvm 1 | org.apache.http.conn.ConnectTimeoutException: Connect to gocd-server:8154 [gocd-server/100.64.93.228] failed: Connect timed out
jvm 1 | at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:151)

Anderson Reyes

@AndersonReyes

Nvm figured it out, the gocd server url was wrong in the cluster config

Karl Herbig

@ccdMuro

Hi, I'm new to GoCD. I searched the documentation for a solution for the following problem I have, but couldn't find one.

Until now I did this my self:
[start Program] -> [little delay] -> [testApi.sh] -> [kill Program]
Now I try to automate it.

I'd like to have a Test Job that
[1] 'starts the already build program' (from the build Job) just to prove it works. // This one works so far
[1.1] This program will not stop by it self so I need a way to kill it at some point in Time.
But,
[2] while this program is running. I'd like to start a Task (bash script) that tests the API towards the program.
After the test script finishes the software should be killed.

Any ideas? :)

marques-work

@marques-work

@ccdMuro sounds like you’re trying to run some kind of smoke or acceptance test. For whichever test framework you are using, shouldn’t it have a way to do setup before running a test suite as well as teardown? Usually one would hook into those to start/stop your program.

But maybe you’re just doing something like:

Start program
Run a bunch of tests using curl to validate the API endpoint
Shut down program

If that’s the case, why not make that a script that starts your program in the background using &, wait for it to finish starting (maybe loop + sleep with curl or something else to detect when it’s done), run your curl tests, then send a kill signal to your background process?

Maybe trap to kill in other failure states too so you don’t accumulate stray processes?

Anyway that’s sort of reinventing the wheel in bash. I’d still recommend using a testing framework in the language of your choice to handle setup, test, and teardown as they are designed to do just that.

Karl Herbig

@ccdMuro

@marques-work you are right, that's it. I'm using curl in my test script.
Thanks for the advise to wrap it all in to a script. I think I will try this first as it fits best into our current environment.
Out of curiosity, what are available frameworks one would recommend for my use case? (I already do unit tests with Catch2)
I'm just at the beginning of my CI/CD and software testing journey, and am thankful for every hint :)

marques-work

@marques-work

There’s so many out there, but it really depends on which language you want to write your tests in.

I would go with whatever you’re comfortable writing in and/or what language is already present on your agents.

For instance, if you have ruby installed, maybe go with test-unit since it comes with ruby (this not requiring dependencies). You can either shell out to curl or use the standard http lib. Otherwise you could use minitest or even rspec if you like spec style tests.

Many Linux distros ship with python installed by default because a lot of system packages depend on it. In that case unittest comes for free, but like ruby, python has many other frameworks.

We could go on about other languages and frameworks, but it’s mostly the same. Use a language that you’re comfortable with that also makes it easy to make http requests or shell out to curl or one that already is present on your agents and go with that, IMO.

I personally prefer interpreted languages because there’s not the extra step of compiling test code. I also prefer using built in frameworks for simple things (unless the API is very hard to use) because I don’t need to manage dependencies. I’m lazy and impatient :).

Karl Herbig

@ccdMuro

@marques-work thank you for your time and advise, I appreciate it :)

marques-work

@marques-work

Do note that using a language other than bash and utils like jq make it easier to assert the structure of repinse code, response headers, response bodies (by deserializing JSON, and inspecting for expected outputs) etc so it may be worthwhile to invest time. Frameworks generally have some useful assertions built-in as well like assertTrue, assertEquals, assertContains, assertMatch etc that might help reduce boilerplate compared to bash.

@ccdMuro of course 👍🏼

Karl Herbig

@ccdMuro

Hi there again :)

I'd like to 'source' a build environment for cross compilation (arm).
I have something like: /opt/poky/2.7.3/environment-setup

Now my task 'source /opt/poky/2.7.3/environment-setup' fails with: Please make sure [source] can be executed on this agent.
If I rewrite my task to 'bash -c source /opt/poky/2.7.3/environment-setup' it works for the task. But the environment does not spread to the current shell so followup tasks can work within it.

What is the proper way of approaching this?

marques-work

@marques-work

Wrap it in a script and execute with bash.

The exec task automatically doesn’t start a shell and invoke commands under the shell; rather, it starts processes by launching executables with the provided args, IIRC.

source is not an executable; it’s a bash builtin

Running bash -c “source my-file.sh” will start a shell, evaluate the script at the top level, and then exit the shell; that’s why it won’t be shared by other tasks.

Now you can either wrap your tasks as a single script or you can use GoCD’s environment variable facilities instead to define the environment at the top level.

evaluate the script at the top level

What I meant to say more clearly is that it will evaluate the script within the bash subprocess you started. It won’t change the environment in the parent.

marques-work

@marques-work

If you wrap your tasks as a script, you could do it inline to your task

bash -c ‘source environment-setup && make` (or whatever your build command is)

Oops, didn’t mean the backtick. Just plain quote.

Karl Herbig

@ccdMuro

I was thinking if I can use the GoCD's environment variable facilities, but that would mean I have to somehow extract all (and there are many) variables by hand, right?

Maybe I go with the 'wrap a script around it' part :D

marques-work

@marques-work

Yeah it sounds like wrapping it is a better option for you

Karl Herbig

@ccdMuro

Thank you again :)

marques-work

@marques-work

👍🏼

Ashley Stovall

@plainsane

I use the script executor plugin in gocd and just ‘. Envs.sh’ and continue on my way

Karl Herbig

@ccdMuro

Uh that sounds interesting, I will try it out on Monday.

buggavep

@buggavep

Hi All, has any one configured this plugin for okta corporate account,
https://github.com/szamfirov/gocd-okta-oauth-authorization-plugin

sam

@shyamnguitar

Hi can i clean up the flyweight directory

As am not able to trigger pipelienes because of space issue

Error : unable to create temporary file: no space left on the device

sam

@shyamnguitar

Just to add if i can clean the flyweight directory , do i need yo restart the pod, as gocd is a pod running in openshift

1 reply

marques-work

@marques-work

It ought to be ok to purge them. They’ll get recreated as needed during material updates. If you want to be really safe, I’d shut down GoCD beforehand so there aren’t any processes locking files (e.g., git fetch or whatever SCM you’re using).

If you know no processes are using them, you could first rename the flyweight directory before deleting to ensure other files within never get locked by GoCD while deleting them if you want to do it without shutting down. mv is atomic on local (non-network) volumes.

marques-work

@marques-work

But I’d just shut down for simplicity.

sam

@shyamnguitar

@marques-work I have released the space however, it has got consumed within no time to 84%. Is there a way to increase the space of flyweight directory and FYI it is not configured to use the PV space.

marques-work

@marques-work

I’m not a kubernetes user so I don’t have any specific advice for you, other than I’m sure your options depend on the type of volume in your pod, so I’d consult the docs.

But basically it sounds like you need to mount a bigger volume to the flyweight mount point.

slankka

@slankka

Hello everyone, I am deploying Gocd in Centos 7, the go-agent cannot register to go-server. even they are in same machine. I have read "Fixing common issues", but it doesn't help.

The error is :
2020-10-15 15:13:17,163 ERROR [scheduler-2] AgentHTTPClientController:105 - Error occurred when agent tried to ping server:
org.springframework.remoting.RemoteAccessException: Could not access HTTP invoker remote service at [http://10.19.15.111:8153/go/remoting/remoteBuildRepository]; nested exception is org.apache.http.client.ClientProtocolException: The server returned status code 403. Possible reasons include:

This agent has been deleted from the configuration
This agent is pending approval
There is possibly a reverse proxy (or load balancer) that has been misconfigured. See https://docs.gocd.org/20.8.0/installation/configure-reverse-proxy.html#agents-and-reverse-proxies for details.

I do not use reverse proxy or load balancer. I have tried to re-install go-server/go-agent, but the problem still happen.

slankka

@slankka

Serveral weeks ago , I deployed 1 server with 4 agents, it works fine. however, this time I do the same things on another machines, it failed.

slankka

@slankka

Well, after uninstalling go-agent and deleting all go-agent folders, finally the deploy successed.

Artem Barbaruk

@artiombarb

Hi, can someone help me with https://github.com/SonicDrivein/gocd-saml-plugin and Azure AD configuration? I have tried to configure but have problem with log in.

kenota

@kenota

Hi all! We are evaluating GoCD as a CD platform for our IT system running in k8s. Our biggest concern at the moment is the use of DinD with privileged mode - this creates a security risk. Does anybody have experience of solving this? Or do you know if there is a roadmap item on solving this issue?

2 replies

marques-work

@marques-work

@kenota I might be mistaken but I thought mounting the docket socket (as in DooD) actually lets you build docker images given that you install the docker binaries in your container?

Alternatively, the link in the docs to jpetazzo’s blog post also mentions sysbox as a solution, but I have zero experience with that so I don’t actually know if it will help you.

kenota

@kenota

@marques-work thank you for the reply. Unfortunately, DooD will not in our case because it will also affect security. We are planning to run our CI server in Kubernetes, giving access to the Docker on the host to GoCD equals to giving a root access to a machine, which we want to avoid.

Aravind SV

@arvindsv

@kenota It depends on your needs / setup, I suppose. GoCD doesn't really know how / what it is doing. If you want to use docker build, you'd need to provide access to it in some way, right? So, in that sense I see this as an issue with how docker works / the docker daemon doesn't work well without root. In this case, I'd look at using something like podman to build images: https://podman.readthedocs.io/en/latest/index.html -- that should allow you to build images, without needing the docker daemon. So, you shouldn't need DinD or DooD.

^ Ideally. I haven't tried it / used it inside a Docker container.

Maybe this helps: https://stackoverflow.com/questions/56032747/how-to-run-podman-from-inside-a-container

Also there are other tools like Kaniko which are usually used for this problem (and others I'm not aware of, for sure).

kenota

@kenota

@arvindsv thank you for the information! We do in fact use Kaniko with jenkins and kubernetes at the moment, but Kaniko is designed to run as a disposable container and not part of something else. My original question was more about practical experience anybody had with GoCD on k8s building docker images without DooD/DinD. Thanks for letting know about podman, did not know about it. There is also buildkit, but question is - what works well in production with GoCD :)

Mahesh Madpathi

@maheshmadpathi

Hello, can someone help me why we get this error?

Error performing command: --- Command ---
git submodule foreach --recursive "git clean -dffx"
--- Environment ---
{}
--- INPUT ----


--- EXIT CODE (128) ---
--- STANDARD OUT ---

--- STANDARD ERR ---
STDERR: fatal: No url found for submodule path 'test-pipeline-gocd' in .gitmodules
---

Where communities thrive

People

Repo info

Activity