• miaws

When git repository faces both 'v-' prefixed version tags and regular tags, it splits them into two groups during sort even when we ask it to sort 'as version numbers'.
This causes wrong 'latest' version detection.

I tried to solve the problem by giving 'v-' prefixed tags higher priority than regular, but this logic sucks when we switch FROM v-prefixed style TO regular.

This problem should be solved with plain JS :(

We should notify that new version of docker image has been deployed to AWS service.

There is official alternative to burrunan/gradle-cache-action we are currently use:
https://github.com/marketplace/actions/gradle-build-action

Consider transition to it as it might be a better solution.

• mistat-server

Current implementation of Jinja2 templating action and Telegram send message action docker builds new image from Dockerfile EACH TIME they are used in new jobs (this causes pip install and other things to be performed). This consumes a lot of worker time when we talk about 100 of notifications.

We should build local docker image, store it in github-ci repository (or somewhere outside) and use prebuilt images in actions.

• All blocks & MiDag are always up to date
• With a handle to restart the server (and erase all data)

• Create actions for git-crypt init
• Add inputs, secrets and steps to work with git-crypt in our standard workflows

From D.Bolotin:

• на тачке должен стоять git-crypt и gpg
• есть переменная в которой лежит ключ (сейчас называется GPG_KEY), чтобы из нее заимпортить ключ в локальную базу gpg надо сделать как-то так:

  echo "$GPG_KEY" > ./private_key.gpg
  gpg --batch --yes --pinentry-mode loopback --import private_key.gpg
  rm private_key.gpg
  

  не пробовал, наверно надо в каком-то докере проверить что это реально работает
  взял отсюда
• потом надо сделать вот так: git crypt unlock

• MiLib
• repseqio/repseqio
• MiXCR

Run milaboratory/github-ci/actions/detect-version@v1
with:
canonize: true
fetch-depth: 100
/usr/bin/git fetch --deepen=1 origin refs/tags/:refs/tags/
From https://github.com/milaboratory/redberry-pipe

• [new tag] 1.0.0 -> 1.0.0
  ! [rejected] 1.1.0 -> 1.1.0 (would clobber existing tag)
• [new tag] v0.9 -> v0.9
• [new tag] v0.9.1 -> v0.9.1
• [new tag] v0.9.2 -> v0.9.2
• [new tag] v0.9.3 -> v0.9.3
• [new tag] v0.9.4 -> v0.9.4
• [new tag] v0.9.5 -> v0.9.5
• [new tag] v0.9.6 -> v0.9.6
• [new tag] v0.9.7 -> v0.9.7
  Error: command "git 'fetch' '--deepen=1' 'origin' 'refs/tags/:refs/tags/'" failed with code '1':

From https://github.com/milaboratory/redberry-pipe

Put custom workflow settings into context

First candidates:

• telegram-target (notifications)
• product-name (notifications)
• product-type (notifications)
• build-category (notifications)

See tg

We need an action to detect list of reviewers allowed to approve deployment to specific environment.

This will allow to mention responsible teammates in 'review is required' notifications.

Current workflow waits for release confirmation and then creates GitHub release along with S3 uploads and docker pushes.

It is much more convenient to have release draft created before confirmation, so developer can change description and add make other manual changes to release before it gets published.

Then, when release is confirmed in CI (environment deployment is approved), existing elease is published by CI automatically.