Configurable interval for GH API

[abskmj]

Hukum should allow to configure the interval at which the GH APIs are called.

[a20185]

We refactored hukum for our in-company Self-hosted Bitbucket Server, in case we add 3 major changes:

• Automatically revalidate and reauthorize for current user, which done by starting a httpServer locally and listens to the server api callback for bypassing current accessToken (aka. ssoids)

• Using Exponential power backtracking for interval decisions, done by a refresh yet request strategy. The Exponential Power Sequence we use is: [1, 2, 4, 4, 8, 8, 8, 16, 16, 16, 16, 16, ... ]. That means, if we stuck at a certain pipeline task for a current period, we should reconsider the need for short intervals. While waiting in the sequence, we just add our timers secondly, but only request while our waiting time actually completes. This will probably cause more waiting time(max 16s) and not-so-accurate time during process running, however will reduce the burden of providing steady polling service for our server. (Sequence pointer will refreshes in a new pipeline procedure)

• Refactor current ref parsers, done by changing the original branch property from parsing git logs manually (by calling git.logs()'s latest property), in order to support the CD jobs triggered by a tag.(current implemantation in hukum only support branch).

Thanks for a such great idea and it's really a productivity tool, hope this will helps~

If needed, we can contribute the implementations to original hukum repo.

[abskmj]

It's good to hear that the tool was helpful. Thanks!

I'm interested to hear more about the third item on the list. Could you describe it ?

[a20185]

The third item aims to distinguish the type of current ref. Which majority can be treated as BRANCH and TAG(detached commit).
In the simple-git package used in hukum, the refs from the latest git log showed in git.log() describes the difference between these two types of git references:

• For BRANCH (Heads), the ref format will be look like: HEAD -> {YOUR_BRANCH_HERE}, blablabla
• For TAG (Detached Heads), the ref format will be look like : HEAD, {YOUR_BRANCH}: {TAG_NAME}, blablabla
  Hence, we can easily judge these two types. In my implementation of our version:

const parseRef = (latestLog) => {
  const refInfo = (latestLog || '').split(', ')
  const headState = refInfo[0].split(' -> ')
  /** Normal head pointer for branch */
  if (headState.length > 1) {
    return {
      ref: headState[1],
      refType: 'branch'
    }
  }
  /** Detached head pointer for tags */
  if (refInfo.length > 2) {
    const tagState = (refInfo[1] || '').split(': ')
    return {
      ref: tagState[1] || '',
      refType: 'tag'
    }
  }
 /** stub fallback */
  return {
    ref: null,
    refType: null
  }
}

and we only need to make a slight refactor to our getInfo function, adding a line after git.log() execution:

/** unrelated codes omitted */
  const log = await git.log()
  // here
  const { ref, refType } = parseRef(log.latest.refs)

p.s. Of course it helps! The importance of the tool is that it can treat as a "local workflow pipeline item". Thanks for hukum, we finally connects local development and remote delivery altogether. For examples:

# open published site after delivery process finished
hukum && open $PROJECT_PUB_URL

# pull for tag updates after delivery for npm-type packages
hukum && git pull `git symbolic-ref --short -q HEAD`

# of course we have the full version of pushing and pulling
git push `git symbolic-ref --short -q HEAD` && hukum && git pull `git symbolic-ref --short -q HEAD`

# after publish npm package, we can update in main repo and then trigger main repo's CD process
git push `git symbolic-ref --short -q HEAD` && hukum && git pull `git symbolic-ref --short -q HEAD` && cd $MAIN_PROJECT_SRC && yarn add $PRODUCT_PACKAGE && yarn pkg:version

# And endless possibilities

[abskmj]

This is great, thanks for the details.