Releases don't seem to be picked up (this is for genius)

Infrastructure
1

So, genius has very old build setup, and I’ve just made a release. I think I’ve correctly set up the whole CI/CD setup to make a tarball but the thing just doesn’t pick it up. The end of the log for the gitlab pipeline thingie the following, which I don’t get as there does seem to be a tarball there, with the right format, the tag is 1.0.28, project name is genius. But upload.sh says nothing is found.

I’m also a bit worried about the whole fact that there does not seem to be any way do this as a dry-run to check for issues like this, seems hell of a lot more complicated than the original master.gnome.org setup.

OK: 48 MiB in 33 packages

$ ls -al “public-dist”

total 2868

drwxr-xr-x 1 root root 40 Mar 5 02:58 .

drwxrwxrwx 1 root root 634 Mar 5 02:58 ..

-rw-r–r-- 1 root root 2935396 Mar 5 02:58 genius-1.0.28.tar.xz

$ echo “Fixing up release tag message for gitlab”

Fixing up release tag message for gitlab

$ a=$(git tag -l $CI_COMMIT_TAG --format=‘%(contents)’)

$ printf ‘%s\n’ “${a%%-----BEGIN*}” > tag_msg.txt

$ cat > upload.sh <<‘EOF’ # collapsed multi-line command

$ bash ./upload.sh “public-dist”

Failed to find any files to upload

1 Like
2

If you could link to the .gitlab-ci.yml you’re using, and some examples of the failing release pipelines, that would probably help people help you.

I’m sure there is a way to dry-run a release, because I remember doing it when first setting up this new pipeline for my projects. But having searched for it on various documentation pages (below), I’m either not seeing it or it’s not documented, so that could probably be improved.

It is more complicated, but it’s also more secure (there is now a chain of trust from the git repository through to the generated tarball where previously there was not) and more maintainable for the sysadmins (not giving people shell access to a GNOME server).

I agree that it’s much more of a pain when things go wrong, as if you push a release tag on a module and then the dist-job fails, that release is complete scrap and typically cannot be recovered. The version number has to be abandoned and a new micro (or nano) release made once the pipeline has been fixed.

Perhaps that could be documented better too.

3

I think it’d be a good starting point for you to read the documentation:

4

Obviously I read the documentation. I would suggest that the documentation should mention this sandbox setup as that’s not in the documentation but as a forum post. Though in any case, that doesn’t solve the issue, it just makes it plausible to debug. I have to admit, I don’t have buttloads of time nowadays and I’ve already spent about 3 or 4 hours just trying to put a tarball at the download location, so I have not in detail read every post and every piece written about this setup, hence my message here to ask someone who has.

Anyway, now that I know how to perhaps try it, I can try and debug it in a few days once I get another 3-4 hours to spend on getting a tarball to upload to the right place.

Anyway the documentation still does not tell me what’s wrong at all, so I’m still stuck where I was.

Best,

Jiri (George)

5

The file is on gitlab in the genius module. Let me paste it here:

include:
  # Use the official GNOME release service component
  # This will handle the upload to download.gnome.org
  - component: "gitlab.gnome.org/GNOME/citemplates/release-service@master"
    inputs:
      job-stage: "release"
      dist-job-name: "build-release-tarball"

stages:
  - build
  - release
# The release service component's release job needs autotools to extract
# the version from configure.ac.
before_script:
  - dnf install -y autoconf automake autoconf-archive

.build-template:
  image: fedora:latest
  before_script:
    - dnf install -y autoconf automake autoconf-archive libtool make gettext-devel intltool pkgconfig xz bison flex
    - dnf install -y gcc gcc-c++
    - dnf install -y glib2-devel gtk3-devel vte291-devel gtksourceview4-devel
    - dnf install -y readline-devel ncurses-devel gmp-devel mpfr-devel

# Regular build to ensure things still compile on branches and merge requests
build:
  extends: .build-template
  stage: build
  script:
    - ./autogen.sh
    - make -j$(nproc)
  rules:
    - if: $CI_COMMIT_TAG
      when: never
    - if: $CI_COMMIT_BRANCH
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'

# Special build that runs only on tags to create the release tarball
build-release-tarball:
  extends: .build-template
  stage: build
  variables:
    # The release service expects the tarball to follow project-version.tar.xz format
    TARBALL_NAME: "genius-${CI_COMMIT_TAG}.tar.xz"
  script:
    - ./autogen.sh
    - make -j$(nproc)
    - make distcheck
    - mkdir -p "${CI_PROJECT_DIR}/public-dist/"
    - cp genius-*.tar.xz "${CI_PROJECT_DIR}/public-dist/${TARBALL_NAME}"
  artifacts:
    name: "${CI_JOB_NAME}-${CI_COMMIT_REF_NAME}"
    when: "always"
    paths:
      - "public-dist"
  rules:
    - if: $CI_COMMIT_TAG
    - if: $CI_PIPELINE_SOURCE == "web"  # Allows manual start from "Build -> Pipelines -> Run pipeline"
      when: manual
6

@jirka I think the reason CI “fails” to find the archive is cause we are looking for a 256sum file of the tarball to be uploaded as well. While the sum its currently not used for something as of now, all build systems produce one automatically and I wanted people to make it available from the start, rather than fixing it down the line.

Additionally, you don’t need TARBALL_NAME if you use a public-dist export directory, your tarballs can be named anything you like.

1 Like
7

Thanks! That helps a lot. I suppose I was mislead by the documentation and should have looked through the code instead :slight_smile: I haven’t yet tested this, but it seems that that should do the trick.

Best,

Jiri

8

I submitted a quick change to the handbook to mention the sandbox template/server. Reviews, and further additions/clarifications to those docs, welcome (feel free to CC me on other handbook MRs for review).

9

Cool. It might be also good to mention the sha256 thing as that’s the thing that stumped me and the information about the public-dist thing (tarballs can be named whatever) as well. See the post by Jordan above.

Best,

Jiri

10

Feel free to submit additional changes like that if you want :slight_smile: