How to make a weekly/nightly release?

[sh-cau]

As described in the title this combination throws an error. I want a nightly release, which does neither get a tag, nor a commit, just a release. I tried to do that using the combination gitPush: false + gitTag: false and publish: true but that results in 422 {message: Ref is not specified} error. I tried every combination (all while publish: true):

gitCommit	gitTag	gitPush	works?
0	0	0	x
0	0	1	x
0	1	0	x
0	1	1	✓
1	0	0	x
1	0	1	x
1	1	0	x
1	1	1	✓

Why does it not work without having to push a tag? I could maybe get rid of it after pushing but this is hacky, i.e., I would have to have rights to delete tags on remote. Also, I would need to delete the release again? Maybe a tutorial would be nice how to do that with nyx or add it as a feature if that is not possible at the moment.

[flelli]

Hi @sh-cau and thanks for your detailed analysis.

The error is due to the fact that releases are required to be tied to a tag which must be already available on the remote repo before creating a release. That's driven by GitHub or GitLab, not Nyx. You can double check by creating a release manually and you'll see a tag is mandatory.

I'll check the docs and prevent the user from getting this error but in any case you can't create a release without a tag.

[sh-cau]

Thank you for the quick reply. I suspected something like this already based on the error message. Then I'll try the hacky way of trying to delete the tag on remote again.

[sh-cau]

For anyone wondering, my workaround is to have the following lines in my .nyx.yml

gitPush: true
gitPushForce: true # not sure if needed
gitTag: true
gitTagForce: true # important to overwrite "weekly" tag
gitTagNames:
  - "{{version}" # without this, I get the REF error again. So we delete it later
  - weekly
publish: true

and my .gitlab-ci.yml looks like this

release-job:
  image: 
    name: mooltiverse/nyx:lastest
    entrypoint: [""]
  script:
    - git checkout $CI_COMMIT_BRANCH # see #280 of nyx issues
    - git reset --hard $(git rev-parse --verify $CI_DEFAULT_BRANCH) # see #280 of nyx issues
    - git config --global user.name $GITLAB_USER_LOGIN
    - git config --global user.email $GITLAB_USER_EMAIL
    - git remote set-url origin "https://PRIVATE-TOKEN:${NYX_RELEASE_TOKEN}@${CI_SERVER_HOST}/${CI_PROJECT_PATH}.git" # see #127 in nyx issues
    - VERSION=$(nyx --summary | awk -F '= ' '/current version/ {print $2}') # VERSION is something like vX.Y.Z-weekly.[0-9]+
      # delete (if present) the weekly release with the same name. Be sure that 'weekly' is in the current version name to not delete any other releases
    - if [[ $(echo "$VERSION" | grep -c 'weekly') -gt 0 ]]; then
        echo "Deleting release matching version $VERSION" &&
        curl --request DELETE --header "JOB-TOKEN:${CI_JOB_TOKEN}" "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/releases/${VERSION}";
      fi
    - nyx --summary --error publish
    # delete the vX.Y.Z-weekly.[0-9]+ tag from remote again to just have the "weekly" tag
    - if [[ $(echo "$VERSION" | grep -c 'weekly') -gt 0 ]]; then
        echo "Deleting tag matching version ${VERSION}" &&
        git push origin --delete $VERSION;
      fi

Unfortunately, you can't get rid of the "{{version}}" in the .nyx.yml because you get the missing REF error again. This is something that @flelli could maybe address, i.e., to rely on any of the tags specified in gitTagNames and not having to rely on the version tag. This would make this hacky solution a little tidier since I wouldn't have to delete the annoying "vX.Y.Z-weekly.[0-9]+" tag from remote after publishing.

[sh-cau]

Further, my company's GitLab instance requires the attached tag to the release to persist. If I delete the tag, the corresponding release also gets deleted, making the above workaround obsolete. I am now trying to not use nyx to publish the release but instead to invoke its infer and make steps and then tag and publish via the Gitlab Release API.

[sh-cau]

I think its still not possible to only have gitTagNames: "stable" or something without having gitTagNames: "{{version}}", too. Why is this not an option, @flelli

[flelli]

It is. Are you experiencing any error in using static tag names instead of templates?