Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

release-tools/publish-releases.sh: New script, to publish staged releases #147

Closed
wants to merge 8 commits into from
Closed

release-tools/publish-releases.sh: New script, to publish staged releases #147

wants to merge 8 commits into from

Conversation

levitte
Copy link
Member

@levitte levitte commented May 24, 2023

This replaces the old do_release.pl, and works with the .dat files that
stage-release.sh produces to get all the information necessary.

By design, this script only handles one type of staged releases per run;
'public', 'premium' and 'security' are staged release types, and they affect
the staging repository that's used. Upload locations / repositories are
determined from the version number of each staged release, unless given on
the command line.

Any set of release files that don't fit the chosen staged release type will
simply be ignored.

The following updates are performed:

  • the source repository is updated with release commits and tag
  • a github release is created in the appropriate repository
  • the release files are copied to the appropriate file service directory
  • omc/data is updated with added lines in newsflash.txt

The extra work surrounding security advisories is not performed by this
script at this stage. That's left for later development.

This also updates release-tools/stage-release.sh to add version information
to the metadata file that release-tools/publish-release.sh can depend on.

@levitte
Copy link
Member Author

levitte commented May 24, 2023

release-tools/publish-release.sh is untested, but should still be
readable enough for commentary. Please have a look and share your
thoughts!

@levitte
Copy link
Member Author

levitte commented May 24, 2023

I've realized that release-tools/publish-releases.sh must have a reviewer option, and must use addrev to add a reviewer record... and this actually answers the question of peer reviewing when we have this automation.

@levitte levitte force-pushed the CT-664 branch 2 times, most recently from 4fe4a74 to 13f1b4b Compare May 30, 2023 06:19
@levitte
Copy link
Member Author

levitte commented May 30, 2023

In all my tests, publish-releases.sh now works properly.

However, we haven't really answered how this will fit with the policy
of peer review, or if we should change that policy. For the moment,
publish-releases.sh doesn't actually offer any review possibility for
actual review, albeit it does run addrev, assuming that review has
been done.

@t8m
Copy link
Member

t8m commented May 30, 2023 •
edited

The e-mail announcement for premium releases needs to be changed to something like this:

   OpenSSL version 1.0.2zh released
   ================================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.2zh of our open source toolkit for SSL/TLS.

   OpenSSL 1.0.2zh is available for download via HTTPS from the following
   location on our support system:

   https://github.openssl.org/openssl/extended-releases/releases/tag/OpenSSL_1_0_2zh

   If you have not yet established access to our support system server,
   please contact us on osf-contact@openssl.org to arrange your set up.

   The distribution file name is:

    o openssl-1.0.2zh.tar.gz
      Size: xxxxxxx
      SHA1 checksum:  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
      SHA256 checksum:  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.0.2zh.tar.gz
    openssl sha256 openssl-1.0.2zh.tar.gz

   Yours,

   The OpenSSL Project Team.

@levitte
Copy link
Member Author

levitte commented May 31, 2023

The e-mail announcement for premium releases needs to be changed to something like this:

That's a change that's associated with the stage-release script, as that's the one that creates these announcement texts. Raise a separate issue for it, as it doesn't belong in this PR.

@t8m
Copy link
Member

t8m commented Jun 1, 2023

The e-mail announcement for premium releases needs to be changed to something like this:

That's a change that's associated with the stage-release script, as that's the one that creates these announcement texts. Raise a separate issue for it, as it doesn't belong in this PR.

OK #157

@levitte
Copy link
Member Author

levitte commented Jun 23, 2023

Unfortunately, this isn't ready yet. Some of the logic isn't quite right...
So, I'm deferring this, as I'm now going inactive for quite a bit of time.

@levitte
Copy link
Member Author

levitte commented Aug 18, 2023

I had hoped to finish this today. Unfortunately, I stumbled on
unforeseen nastiness, and will continue Sunday night or Monday
morning.

@levitte
release-tools/publish-releases.sh: New script, to publish staged rele…
a5e0876 
…ases

This replaces the old do_release.pl, and works with the .dat files that
stage-release.sh produces to get all the information necessary.

By design, this script only handles one type of staged releases per run;
'public', 'premium' and 'security' are staged release types, and they affect
the staging repository that's used.  Upload locations / repositories are
determined from the version number of each staged release, unless given on
the command line.

Any set of release files that don't fit the chosen staged release type will
simply be ignored.

The following updates are performed:

- the source repository is updated with release commits and tag
- a github release is created in the appropriate repository
- the release files are copied to the appropriate file service directory
- omc/data is updated with added lines in newsflash.txt

The extra work surrounding security advisories is not performed by this
script at this stage.  That's left for later development.

This also updates release-tools/stage-release.sh to add version information
to the metadata file that release-tools/publish-release.sh can depend on.
@levitte
release-tools/publish-releases.sh: Set defaults from environment vari…
a8cc06b 
…ables

This makes it possible to setup a test environment for staging and publishing.

This also modifies stage-release.sh's option --staging-address to
--staging-location, to reflect that it may also be a local directory.
@levitte
release-tools/publish-releases.sh: Add the manual
43db03d
@levitte levitte marked this pull request as ready for review August 22, 2023 09:19
@levitte
Copy link
Member Author

levitte commented Aug 22, 2023

This is now ready for review. I haven't tested everything yet, and am
reviewing the details in the manual, but am now confident enough that
this is sane enough.

@levitte
Copy link
Member Author

levitte commented Aug 22, 2023

Of course, it's at this time that I'm realising some options aren't
quite right. Please stay tuned.

@levitte
Copy link
Member Author

levitte commented Aug 22, 2023

Change made, and this looks more sane to me

@levitte
release-tools/publish-releases.sh: Remove the --custom option
dca781f 
This was useful once, but isn't any more.  Setting appropriate environment
variables has the same effect, and is easier to handle.
@levitte
release-tools/publish-releases.sh: Change the behaviour for signing
089b45f 
Signing of release files and tags is now only done if it hasn't been done
by stage-release.sh.
@levitte
release-tools/publish-releases.sh: Change staging types to 'ordinary'…
1021123 
… and 'security'

Having the staging types 'public', 'premium' and 'security' was nonsense,
we don't really have that sort of division.  'ordinary' and 'security'
staging makes more sense for what we do, and that leaves it to the script
to fully determine for each version being released if it should become a
public or a premium release.
@levitte
release-tools/{stage,publish}-releases.sh: Better gpg handling
289c6d4 
gpg is very annoying with how it prompts for pass phrases.  However, it's
possible to tell it to use the terminal with '--pinentry-mode loopback'.
In turn, git is annoying with how one can't specify gpg options directly;
instead, a small script that does the right thing is produced, and passed
to git with the gpg.program config option.
@arapov
Copy link
Member

arapov commented Sep 26, 2023

Looks like not needed. Candidate to be dropped.

@levitte
Copy link
Member Author

levitte commented Sep 26, 2023

I'm happy to drop it.

Something I realised on last release is that producing the draft release on github should probably be part of staging a release, leaving only pushing "Publish Release" to actual publication...

@arapov
Copy link
Member

arapov commented Jan 22, 2024

Became irrelevant.

@arapov arapov closed this Jan 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
Project Board
Status: Done
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
3 participants
@levitte @t8m @arapov