Error running garbage collection - the pack file might be corrupt: Unknown object type 0 about gocd HOT 9 CLOSED

There's no magic built in to push to a remote, but it's just a regular git repository so you could cron/supervisord something that does this periodically using command line git.

Alternatively, and probably better, just rely upon the built-in scheduled backup feature which includes zips of the configuration db/repo: https://docs.gocd.org/current/advanced_usage/one_click_backup.html ...

Or rely on lower level filesystem snapshot backups of your NFS volume.

from gocd.

Yuck, this is unfortunate. Never seen that before (probably the beauties of NFS?) It is possible to have the GoCD config repo bootstrapped from and pushed to a remote, but I've personally been unsure of the merits of that. In any case, that won't help you now.

I believe it should be possible to start fresh with git init like you suggest, but you will also need to add+commit the existing cruise-config.xml before GoCD will handle it correctly at startup. Branch will need to be master. If you want to reverse engineer from how the code behaves at start-up/initialization you can check here.

You'll definitely lose the ability to see the "Config Changed" history between pipeline runs, but I think that it will otherwise work OK.

I'd suggest you experiment with your process on a local GoCD first, either via a container with a mounted /godata or just via https://www.gocd.org/test-drive-gocd.html - doesn't have to be with your "real" config repo, perhaps just one with a few manual commits driven by the GoCD UI or a few pipeline runs with config changes between them.

As to your performance/CPU issues, it would sound odd to me if it's causing that, but it's probably wise to fix this first before digging too deeply into that.

from gocd.

Thanks for getting back to me, I've been having a bit of play around with our test GoCD instance and deleting and re-initialising the Git repo does seem to work as expected, I've got a bit more testing to do but it's looking promising so far.

Before I do the work in production, you mentioned that the GoCD config can be automatically pushed to a remote. Given what's happened, it sounds like a good idea for us to look into doing that. However, I was unable to find any information about how to do that anywhere, do you know of any resources that exist?

from gocd.

from gocd.

My apologies. I realised that I might delete that code snippet by accident. Here's the actual code :

#!/bin/bash

# Define your local Git repository path
repo_path="/path/to/your/git/repository"

# Define your remote repository URL
remote_url="[email protected]:user/repository.git"

# Function to push changes
push_changes() {
    cd "$repo_path" || exit
    git push origin master # or your preferred branch
}

# Watch for changes using inotifywait
inotifywait -r -m -e modify,create,delete,move "$repo_path" |
    while read -r directory events filename; do
        # Only act when changes occur in the Git repository
        if [[ "$directory/$filename" =~ ^$repo_path ]]; then
            echo "Changes detected in $directory/$filename. Pushing changes..."
            push_changes
        fi
    done

from gocd.

Thanks both, I've now fixed the Git repo in our production GoCD instance. I struggled to figure out the commit message format it needed with the correct checksums and things, it was always coming up with an error, but I found that just doing the git add without the git commit was sufficient and GoCD would detect this and do the commit for me.

We elected not to use a remote for the time being, if we see this issue again that we'll look to potentially do that. For now, we're chalking it up to a blip.

from gocd.

If you don't have it configured already, it's still a very good idea to be using at least the built in GoCD backup function. That's relatively trivial to set up since GoCD manages the cron and would have allowed you to roll back somewhere with this without losing everything.

from gocd.

Thanks Chad, we do have backups configured and keep them for 14 days, but this issue with the corruption has been around since at least early February (as far back as our logs go, likely much longer), so would be no use in this case unfortunately.

from gocd.

Fair enough. Could consider keeping them for longer I suppose. Shouldn't be too large in size once compressed?

from gocd.