As Andrea Veri hinted in his previous post, a new service called GNOME Release Service is coming soon to simplify, automate, and better secure the process of uploading module releases to download.gnome.org.
The date this service is planned to enter production (and consequently retire the ftpadmin script) is set for 11th December.
You can soon expect the current guide, Making a Release, to be updated with a detailed explanation on how to fully utilize this new feature in your GitLab CI.
That’s really amazing! The idea of having something better than ftpadmin is not new. Which is a way of highlighting that actually implementing this is pretty darn impressive. Thanks!!
Hi,
this might be kinda weird, but just an idea: would it make sense to
allow some transition period, instead of expecting each and every
maintainer to spend the Christmas time and the beginning of the year on
some hit & miss trial with the GitLab CI? It’s obviously not fully
tested on all edge cases, neither documented yet (as of today), thus
the decision to cut the line without a fallback is rather weird.
I mean, this feels like kinda in rush. Is there any (good) reason for
such rush and pressure on all of the GNOME folks? You know that not
everybody is in a full time job on their GNOME projects, do you?
This work has been in progress for more than six months, and was announced last month as part of the transition to the new infrastructure. The next alpha release is going to be on the first week of January, which means you have four weeks to modify your CI pipeline.
Let’s also be honest: if there were no deadline, or we waited for another cycle, nobody would have done anything until the very last minute anyway, and we’d have the exact same response only six more months later.
which means you have four weeks to modify your CI pipeline.
Well, in fact, when you subtract the Christmas time, then it’s like 3
weeks or less. For me personally, I’m gone since this very Friday, back
on the January 6th, thus I’ve two and a half days to play with an
undocumented thingy, which I even do not know how to test, and, most
importantly, I’ve other things I want to finish before I’m gone.
I did want to spend a bit of time on the release on the January 6th,
but with this change do not expect me doing the release on time. I
guess it’ll be the first time I’ll be late for all those years I do the
releases, but my memory is rusty, I could be late before too, I just think I never was.
we’d have the exact same response only six more months later.
I hope not, but I agree it’s likely (even not from me, really, just
give a me a test environment where I cannot break anything and I can
dive into it at the beginning of the next year).
Setting up a CI job takes about 10 minutes, and you cannot “break” anything. At most, if you’re like me and don’t set up all the bits prior to it, you are just going to waste release versions, since you cannot force push or delete tags.
I’ve literally done this for JSON-GLib, from scratch, and it took about an hour of work in total, because I made all the possible mistakes in order to get an upper limit to the time and effort involved:
set up a CI job and introduced external changes which required fixing the pipeline first
tagged the wrong commit instead of the one with the release, and the service rejected the tarball with a non-compliant name
bumped the version, tagged the appropriate commit, but forgot to protect the *.*.* tags in the repository options, and the service rejected the upload
bumped the version, tagged the appropriate commit, and protected the tag
Even accounting for human error and unfamiliarity with CI pipelines, and for projects that take more than 5 minutes to run a release pipeline, this whole process is going to take a very small amount of time.
Heh, nice to hear your opinion. I’m different, it’s not going to take
10 minutes for sure. I’m very unfamiliar with CI, I never needed it,
thus it’s all new. The CI I use was done by someone else, copied over
or somehting. The YAML? The same thing. For someone starting on a
green/empty place, the learning curve is not about doing human
mistakes, it’s about doing all wrong, with occasional “oh, this might
be probably it after all” and chasing the documentation for what
variables are for what, and which are available and which not, it’s not
a question of 5/10 minutes, really. Again, zero knowledge here, I’m
sorry.
Even if the idea of changing the way the release is going to be done
was 6 months ago, there is 0 documentation for it (for our/me
uneducated) after those 6 months, not on the place where it was
announced it’ll be (see the start of this thread or how you call it in
the Discourse world). No test environment. Is wasting version tags
fine? You know people can use the tags instead of the tarballs, right?
Then they get nonsense, or, well, incomplete things. Not nice, not
helpful. Despite countless brown-paper-bag bugs I do all the time I do
test the things before I publish them. Doing this completely untested
feels wrong. (I still recall how I broke the code just before going on
holidays, that was something memorable, to not do it again).
Anyway, I might be the only one old uneducated here. No need to worry,
the things will settle in time. I’m sorry for wasting your time.
Hi, unfortunately our sysadmins want to retire master.gnome.org immediately as part of infrastructure modernization work, so looks like it’s likely to happen tomorrow.
Don’t worry about missing the tarball deadline in early January! Of course it’s nicer if alpha releases are not late, but we understand that changing how releases work is an exceptional situation and it may take maintainers some time to adopt the new CI rules. Hopefully it should not be especially difficult, but of course learning new processes can be challenging. Release team is happy to help if you run into trouble.
(Another consequence is that projects without CI may no longer create releases. There are fortunately not very many of these left. Release team can help set up CI if you don’t know how.)
Hi,
okay, thank you. I kinda prefer to know how the things work, thus I can
use it properly. The current CI for the projects I maintain is kind of
“it seems to work as I’d like it to work”, but I cannot tell whether it
could do better (it probably can). Doing changes blindly is something I
prefer to avoid, even I agree it can be “unavoidable” in some cases.
I still think this is in rush. The migration (as named to be the reason
for the master.gnome.org closure) was done prematurely, because the
GNOME GitLab instance was useless for some weeks. Not being that, I
suppose the closure would be done later instead. I do not know whether
there was any way to do the releases through the CI before. I think I’m
subscribed to all the proper channels, but it can be I missed it. If by
any chance I did not miss it, not being able to test the changes with a
backup plan in case things go havoc is a proper way to deliver changes
to fundamental processes, at least from my point of view.
I guess I’ll create some broken tags, like 0.0.1, 0.0.2, …
0.0.1000000, to test the changes, and only then I’ll use the right
version number. Whom will clean up download.gnome.org I do not know.
The tarball will end in there, right? False mail notifications
“expected”. The tags should be dropped as well, but I understood from
the posts that “cannot be done”. I did not try it though. Something for
the next year.
Hmm, okay, then I’m back at the square one. How do I test my changes
work as expected and as intended? I’ve not much idea how the things
should work under the hood, the “Making a release” page (link at the
first post) is still quiet, it references the master.gnome.org . I do
need to test what I’m doing, especially with such an important thing
like the release is.
Hello, a post about a sandbox environment supposed for testing this process was just published, please take a look and I hope that it will help you out preparing for releasing with the new procedure.