fac/fa-harness-tools

Tools and preflight checks for deployments with Harness.io

fa-harness-tools's Issues

Run specs with CI

Specs ought to be running on a CI platform - could use GitHub Actions even, or Circle/TravisCI.

Slow check-forward-deploy check when there are many tags

The check-forward-deploy check (and probably check-recent-deploy) is very slow when operating on a repo with over 16,000 tags, taking about 10 minutes.

It tries to determine the last deployment tag for the environment:

fa-harness-tools/lib/fa-harness-tools/check_forward_deploy.rb

Lines 19 to 20 in 2df0cb6

	current_tag = @client.last_deploy_tag(
	prefix: @tag_prefix, environment: @context.environment)

However this relies on loading all tags from the GitHub API with pagination and filtering them by prefix:

fa-harness-tools/lib/fa-harness-tools/github_client.rb

Lines 25 to 28 in 2df0cb6

	@octokit.auto_paginate = true
	@octokit.tags(owner_repo).find_all do |tag|
	tag[:name].start_with?("#{prefix}-#{environment}-")
	end

We need a more optimised way of finding the latest deployment tag. Possibly:

1. Check for a better API, see if we can filter by prefix. If octokit can't do it, check the newer GraphQL API.
2. If we can filter by prefix, we may also need to filter by recent dates as we still have lots of deploy-production prefixed tags.
3. Check for an API that returns a list guaranteed to be sorted.
4. Caching.

Add automated Gem release

• Add a GitHub action that automatically releases the gem after merging to master

Command output is unfriendly

The output from the commands is particularly unfriendly and should be easier to read in a hurry. I had copied it from our previous pre-flight checks, but I don't think there's any reason to keep it that way.

Example output:

INFO   2019-11-27 09:10:33    scheduled deploy time
INFO   2019-11-27 09:10:33    master contains 6b252b906102b869add9843017892083e9519ef0
ERROR   2019-11-27 09:12:07    6b252b906102b869add9843017892083e9519ef0 is prior to no.3 most recent commit with "harness-deploy" tag

It would be better if each check could output its name and description/purpose, so it's easier to see which check is generating which bit of the output.

The messages should then help explain what it's checking for, which versions/commits it's using for the check (as debug) and a clearer description of what's wrong and what the user might do about it.

is_ancestor_of? is very slow to fail

The GithubClient#is_ancestor_of? method is very slow to fail on a repo with a lot of history. This is noticeable when a check-recent-deploy or check-forward-deploy check is going to fail - but it's OK and fast in the usual successful case.

Its purpose is to find whether commit X includes commit Y (the ancestor) in its history. It does this by loading commits from X and working backwards, looking for Y. In the normal case it's going to finish quickly as there are unlikely to have been many commits since the last deployment. In the negative case then it has to load every commit from X back to the root of the repo history.

It could be optimised to only look at commits within a certain timeframe, or only a certain number of commits (though it would be a problem after merging many new commits). It might also be possible to get a more direct answer from the GitHub API about whether two commits are related.

Add specs for GithubClient

The GithubClient class needs some spec coverage. Perhaps via VCR or similar stubbing method for GitHub, or integration tests against a real GitHub repo.

check-schedule is hardcoded

check-schedule is mostly hardcoded behaviour and should be more configurable:

• The schedule itself is fixed Mon-Thu 9am-4pm, Fri 9-12, but it should be easy to set your own. Perhaps pass an argument that adds schedules, e.g. --schedule "* 9-15 * * mon-thu" --schedule "* 9-11 * * fri"
• The timezone is fixed to Europe/London

Make GITHUB_OAUTH_TOKEN optional

The OAuth token is optional really, it's only necessary for private repo access. The command line tools shouldn't require it.