Month: May 2018

Posted on

Local Jira server install: Unable to search: “An unknown error occurred while trying to performa search”

On starting up my VM where I have Jira installed, all my logged issues are not displaying, and there’s errors about searching and indexing:

On the Admin / Advanced / Indexing page it shows:

This page on search and indexing issues and a number of other pages and articles talk about deleting the temp Lucene index and cache files, but the docs and other posts miss the important part of stating where these files are.

This page gives a good overview of the file structure of Jira, but doesn’t talk about the Lucene indexes.

This page talks about deleting the Lucene indexed at $JIRA_HOME/caches/ but doesn’t say where $JIRA_HOME points to. It isn’t the /opt/atlassian/jira directory structure mentioned by the previous article, but there isn’t a caches there or anywhere below that directory.

Not knowing where else to look, I just did a find from the root for ‘caches’ and found the location elsewhere here:

$ sudo find . -type d -name caches

./var/atlassian/application-data/jira/caches

Ok. Stopping my server with

sudo /etc/init.d/jira stop

and then moving the caches/indexes folder to indexes-old, retstarting Jira with:

sudo /etc/init.d/jira start

and now there’s a new error about Lucene:

Ok. Clicking the Find out More link shows the results of this health check:

Clicking the How do I resolve this link takes you to this page, which suggests to do a re-index, which is from the Admin / Advanced / Indexing page and where I got the second error originally. Going back there and trying the ‘lock and re-index’ option which was recommended in some of the other index related issus posts:

I then got this:

Ok, no errors! Let’s see if my logged issues are back.

They’re back! Now I’m back in business!

 

Posted on

Building and deploying Docker containers using GitLab CI Pipelines

As part of migrating this blog to Docker containers to move to a different VPS provider (here, here and here), I found myself repeating a number of steps manually, which always a good indication that there’s an opportunity to automate some or all of those steps.

Each time I made a change in the configuration or changed the content to be deployed, I found myself rebuilding the Docker image and either running locally, pushing to my test server, and eventually pushing to my prod VPS and running there.

I’m using a locally running GitLab for my version control, so to use its build pipeline features was a natural next step. I talked about setting up a GitLab runner previously here – this is what performs the work for your pipeline.

You configure your pipeline with a .gitlab-ci.yml file in the root of your repo. I defined 2 stages, build and deploy:

stages:
 - build
 - deploy

For my build stage, I have a single task which is to build my images using my docker-compose.yml:

build:
 stage: build
 script:
 - docker-compose build
 tags:
 - docker-test

For my deploy steps, I defined one for deploying to my test server, and one for deploying to my production VPS. This is the deploy to my locally running Docker server. It changes DOCKER_HOST to point to my test server, and then uses the docker-compose.yml again to bring down the running containers, and bring up the new containers with the updated images:

deploy-containers:
 stage: deploy
 script:
 - export DOCKER_HOST=tcp://192.x.x.x:2375
 - docker-compose down
 - docker-compose up -d
 tags:
 - docker-test

And one for my deploy to production. Note that this step is defined with ‘when: manual’ which tells GitLab the task is only run manually (when you click on the ‘>’ run icon):

prod-deploy-containers:
 stage: deploy
 script:
 - pwd && ls -l
 - ./docker-compose-vps-down.sh
 - ./docker-compose-vps-up.sh
 when: manual
 tags:
 - docker-prod

Here’s what the complete pipeline looks like in GitLab:

With this in place, now any changes committed to the repo result in a new image created and pushed to my test server automatically, and when I’ve completed testing the changes I can optionally deploy the changes to my prod VPS hosted server.

 

 

 

 

Posted on

Selecting a hidden file from the MacOS File Chooser dialog

I’ve wondered a couple of times how you can navigate to a hidden folder and/or select a hidden file when an app requires you to pick a file using MacOS’s file chooser, because by default neither are visible in the chooser.

A quick search found this post and the easy but not so obvious answer is to use either:

  • Shift + Command + . to show/hide hidden files/folders
  • Shift + Command + G to get the ‘Go to Folder’ dialog where you can type in the folder name if you already know where you’re trying to browse
Proudly powered by WordPress