New way of releasing GTK-Doc

Platform
1

Hi,

From now on, only a git tag is created for releasing GTK-Doc, and tarballs are no longer uploaded to download.gnome.org.

(So GitLab CI has not been set up for uploading tarballs to download.gnome.org).

Best regards,
Sébastien

1 Like
2

Could you consider creating GitLab releases? I can get notified by GitLab for created releases, but not for created tags.

It’s possible to create a pair of CI jobs that automatically create a release from a pushed tag’s subject and body. They look like this:

prepare release:
  stage: release
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - git for-each-ref --format='RELEASE_NAME=%(contents:subject)' refs/tags/$CI_COMMIT_TAG >release.env
    - git for-each-ref --format='%(contents:body)'                 refs/tags/$CI_COMMIT_TAG >release.description
  artifacts:
    paths:
      - release.description
    reports:
      dotenv: release.env

make release:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  needs: ["prepare release"]
  rules:
    - if: $CI_COMMIT_TAG
  script:
    - echo "Releasing $CI_COMMIT_TAG ($RELEASE_NAME)"
  release:
    name: "$RELEASE_NAME"
    description: "./release.description"
    tag_name: "$CI_COMMIT_TAG"
    ref: "$CI_COMMIT_TAG"
3

It’s possible to write a script to watch for new git tags. And that way it works regardless of where the git repo is hosted.

I prefer really the bare minimum for releasing new versions. GTK-Doc is not the only project that I work on, and doing releases can be time consuming (BTW, maintaining CI is also time consuming).

How would you watch for new releases if the git repo was hosted simply on a basic server, without a platform like GitLab or equivalent?

4

Somebody has already updated release-monitoring.org. Thanks for that.

I’ve also removed gtk-doc from Fedora’s mclazy, which updates GNOME packages automatically.

5

Sorry, but because gtk-doc is a GNOME module that is still part of the GNOME SDK, it is required for it use the GNOME Release Service (or equivalent I guess) so that tarballs are uploaded to download.gnome.org . We can help set up the CI for you if needed. Once it’s working, it shouldn’t be more work than pushing a git tag and avoiding breaking the CI.

6

I’m not familiar with the GitLab CI, if someone can help me to set it up (only for uploading tarballs), then I’m all for it.

But I’ll not watch the CI notifications to maintain it, so if it breaks for doing a next release, someone else will need to fix the CI first. Is there already a “CI team” or something broader?

7

Watching and maintaining CI is really a baseline expectation for a GNOME maintainer (and really any open source project maintainer). It’s not hard.

We have developers who are happy to initially set up CI for you, and help if you encounter a problem that you don’t know how to fix. But they’re not going to want to babysit it for you. And if you intentionally merge commits when CI is failing, well there’s not much point in having it. That will also result in your release tarball not being uploaded.

8

I still would prefer to delegate the CI maintenance to someone else. The good thing is that there can be several maintainers for a single module. Or before attempting to do a release, if I see that CI is broken I’ll ask for help. For gtk-doc there is no rush anyway.

For me gtk-doc is volunteer work, sometimes I devote a bit of time to it, but that’s it.

For all the other modules I maintain CI is not used at all. I feel that over time, we ask more and more things that developers are supposed to do, and at some point it becomes too much (which leads to stress).

9

@alatiera has added CI for gtk-doc for uploading the tarballs.

And I have released a new version, appearing again on download.gnome.org as expected.

1 Like
10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.