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.

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

[Rel-Eng]: Adds script to automatically generate GHCup metadata for Cabal releases #9411

Merged
merged 6 commits into from
Dec 16, 2023

Conversation

arjunkathuria
Copy link
Contributor

@arjunkathuria arjunkathuria commented Nov 6, 2023

Draft PR for feedback and suggestion for issue #9298

The problem

Currently, on a cabal release, for it to be released by GHCup, the metadata of the release required by GHCup is manually generated. The process seems quite arduous and is an overhead for a release manager.

The solution

This PR intends to introduce a script that would help make cabal releases easier and more streamlined by automatically generating the required cabal release metadata in the correct format that is usable by GHCup as-is. It then essentially becomes a simpler affair for the release manager to introduce the new release in GHCup.

The link in the issue 9298 thread was used as a reference for this script.

Current Progress

The basic core functionality of the script works, as in, if you give it a release number as it's first and only argument, it generates the metadata for that release which can be used drop-in by GHCup. An example of the output to follow in the first comment of the PR.

More sections and info TBD

Todos

  • figure out the correct directory to CD into for artifacts/downloads (the line here)
  • verify which directory the script should reside in. It currently resides in the top level scripts/release directory.
  • TBD based on reviews and feedbacks.

@arjunkathuria
Copy link
Contributor Author

arjunkathuria commented Nov 6, 2023

The usage and current output result after executing the script can be seen as below:-

usage

$ create-release-metadata-for-ghcup.sh "3.10.2.0"  

or, without the quotes

$ create-release-metadata-for-ghcup.sh 3.10.2.0

both should work.

The output

The script being used as mentioned above generates the metadata for the release in the following format, which can be used by GHCup drop-in. The output of the script for release version "3.10.2.0" can be seen below.

    3.10.2.0:
      viTags:
        - Latest
      viChangeLog: https://github.com/haskell/cabal/blob/master/release-notes/cabal-install-3.10.2.0.md
      viPostInstall: *cabal-31020-post-install
      viArch:
        A_64:
          Linux_UnknownLinux:
            unknown_versioning: &cabal-31020-64
            dlUri: https://downloads.haskell.org/~cabal/cabal-install-3.10.2.0/cabal-install-3.10.2.0-x86_64-linux-alpine3_12.tar.xz
            dlSubdir: cabal-install-3.10.2.0
            dlHash: b54e1cd235c47c62c03cdb9f6cf90e5fe8ae38c5e5befb9e21c8d1395f4bde05
          Linux_Alpine:
            unknown_versioning: &cabal-31020-64
          Linux_CentOS:
            unknown_versioning: &cabal-31020-64-centos7
            dlUri: https://downloads.haskell.org/~cabal/cabal-install-3.10.2.0/cabal-install-3.10.2.0-x86_64-linux-centos7.tar.xz
            dlSubdir: cabal-install-3.10.2.0
            dlHash: cfcdab399380dec7fedda55898bff975ac30b5d5d579433cbf8773b17c15f410
          Linux_Debian:
            ' ( >= 9 && < 10)': &cabal-31020-64-debian
              dlUri: https://downloads.haskell.org/~cabal/cabal-install-3.10.2.0/cabal-install-3.10.2.0-x86_64-linux-deb9.tar.xz
              dlSubdir: cabal-install-3.10.2.0
              dlHash: af5ce42114cf7720c37fee3238781df4c75bb74914c62e6a68833fb434e0cad7
            ' ( == 10 && < 11)':
              dlUri: https://downloads.haskell.org/~cabal/cabal-install-3.10.2.0/cabal-install-3.10.2.0-x86_64-linux-deb10.tar.xz
              dlSubdir: cabal-install-3.10.2.0
              dlHash: bdeb27c008b09c3b86f8a2768018d62a1aee02565304d123fda87ed432549418
            ' ( >= 11)':
              dlUri: https://downloads.haskell.org/~cabal/cabal-install-3.10.2.0/cabal-install-3.10.2.0-x86_64-linux-deb11.tar.xz
              dlSubdir: cabal-install-3.10.2.0
              dlHash: 9ca5625c89e8fcada02edced5048c3a3db0254e2bef1eb792d549d633222b108
            unknown_versioning: &cabal-31020-64-debian
          Linux_Fedora:
            '>= 33':
              dlUri: https://downloads.haskell.org/~cabal/cabal-install-3.10.2.0/cabal-install-3.10.2.0-x86_64-linux-fedora33.tar.xz
              dlSubdir: cabal-install-3.10.2.0
              dlHash: 1e59dc1e1a1b33085a1789b8ddafb55026211454efe0b4e814c956ef86fe3ea5
            unknown_versioning: &cabal-31020-64-centos7
          Linux_Ubuntu:
            '< 20': &cabal-31020-64-ubuntu18
              dlUri: https://downloads.haskell.org/~cabal/cabal-install-3.10.2.0/cabal-install-3.10.2.0-x86_64-linux-ubuntu18_04.tar.xz
              dlSubdir: cabal-install-3.10.2.0
              dlHash: 7b0bb22c263ae0b43459de1995bf465560d412c12d47af011b2ac27b5d30c7aa
            '>= 20': &cabal-31020-64-ubuntu20
              dlUri: https://downloads.haskell.org/~cabal/cabal-install-3.10.2.0/cabal-install-3.10.2.0-x86_64-linux-ubuntu20_04.tar.xz
              dlSubdir: cabal-install-3.10.2.0
              dlHash: c2a8048caa3dbfe021d0212804f7f2faad4df1154f1ff52bd2f3c68c1d445fe1
            unknown_versioning: *cabal-31020-64-ubuntu18
          Linux_Mint:
            '< 20': *cabal-31020-64-ubuntu18
            '>= 20': *cabal-31020-64-ubuntu20
            unknown_versioning: *cabal-31020-64-ubuntu18
          Darwin:
            unknown_versioning:
              dlUri: https://downloads.haskell.org/~cabal/cabal-install-3.10.2.0/cabal-install-3.10.2.0-x86_64-darwin.tar.xz
              dlSubdir: cabal-install-3.10.2.0
              dlHash: cd64f2a8f476d0f320945105303c982448ca1379ff54b8625b79fb982b551d90
          Windows:
            unknown_versioning:
              dlUri: https://downloads.haskell.org/~cabal/cabal-install-3.10.2.0/cabal-install-3.10.2.0-x86_64-windows.zip
              dlSubdir: cabal-install-3.10.2.0
              dlHash: b09e335b2ebeafa1db5e1e5614e3e10fb37da230a36865d76646ab27b2f3f46b
          FreeBSD:
            unknown_versioning:
              dlUri: https://downloads.haskell.org/~cabal/cabal-install-3.10.2.0/cabal-install-3.10.2.0-x86_64-freebsd.tar.xz
              dlSubdir: cabal-install-3.10.2.0
              dlHash: 6dcd9d38a9f2101a0a3c3b74cacb2e41b8f7226f181780c0f872f2f1206dee37
        A_32:
          Linux_UnknownLinux:
            unknown_versioning: &cabal-31020-32
              dlUri: https://downloads.haskell.org/~cabal/cabal-install-3.10.2.0/cabal-install-3.10.2.0-i386-linux-alpine3_12.tar.xz
              dlSubdir: cabal-install-3.10.2.0
              dlHash: e219d2c6446c29e09644c4f064f4b87d486871ad6f6de16f0d2fcbd8626b5a5b
          Linux_Alpine:
            unknown_versioning: *cabal-31020-32
          Linux_Debian:
            '( >= 9 )':
              dlUri: https://downloads.haskell.org/~cabal/cabal-install-3.10.2.0/cabal-install-3.10.2.0-i386-linux-deb9.tar.xz
              dlSubdir: cabal-install-3.10.2.0
              dlHash: 2b26d2cb67f1ba3561509fbccc30810ccc1c5032238fca00666e3dcd03e941a8
            unknown_versioning: *cabal-31020-32
        A_ARM64:
          Darwin:
            unknown_versioning:
              dlUri: https://downloads.haskell.org/~cabal/cabal-install-3.10.2.0/cabal-install-3.10.2.0-aarch64-darwin.tar.xz
              dlSubdir: cabal-install-3.10.2.0
              dlHash: d2bd336d7397cf4b76f3bb0d80dea24ca0fa047903e39c8305b136e855269d7b
          Linux_Debian:
            '( >= 10 && < 11)': &cabal-31020-arm64
              dlUri: https://downloads.haskell.org/~cabal/cabal-install-3.10.2.0/cabal-install-3.10.2.0-aarch64-linux-deb10.tar.xz
              dlSubdir: cabal-install-3.10.2.0
              dlHash: 004ed4a7ca890fadee23f58f9cb606c066236a43e16b34be2532b177b231b06d
            '( >= 11)':
              dlUri: https://downloads.haskell.org/~cabal/cabal-install-3.10.2.0/cabal-install-3.10.2.0-aarch64-linux-deb11.tar.xz
              dlSubdir: cabal-install-3.10.2.0
              dlHash: daa767a1b844fbc2bfa0cc14b7ba67f29543e72dd630f144c6db5a34c0d22eb1
            unknown_versioning: *cabal-31020-arm64
          Linux_UnknownLinux:
            unknown_versioning: *cabal-31020-arm64

Notes on output :-

The output for release "3.10.2.0" from running this script is almost identical when compared to what is currently deployed at GHCup for this release .

The SHA256 hashes match and the urls are identical (except for the ~cabal part).
There are certain differences like an addition of dlSubdir part in most sections.


RELEASE=$1
## FixMe:// What dir to use here?
## cd "gh-release-artifacts/Cabal-${RELEASE}"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hasufell what would the dir here be?

@arjunkathuria
Copy link
Contributor Author

It just occurred to me that they (@Kleidukos , @hasufell ) might have notifications off for draft PRs.
un-drafting for now.

@arjunkathuria arjunkathuria marked this pull request as ready for review November 10, 2023 20:00
@Kleidukos
Copy link
Member

@arjunkathuria indeed, drafts are not meant to be reviewed. :)

@Kleidukos
Copy link
Member

@arjunkathuria can you run shellcheck on your script?

@arjunkathuria
Copy link
Contributor Author

@Kleidukos just did, came out clean.

image

Copy link
Member

@Kleidukos Kleidukos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only one change and it should be good 👍

scripts/release/create-release-metadata-for-ghcup.sh Outdated Show resolved Hide resolved
@hasufell
Copy link
Member

This script only works well in conjunction with a script that downloads artifacts into a specific dir.

See https://github.com/haskell/haskell-language-server/blob/master/scripts/release/download-gh-artifacts.sh

@arjunkathuria
Copy link
Contributor Author

This script only works well in conjunction with a script that downloads artifacts into a specific dir.

See https://github.com/haskell/haskell-language-server/blob/master/scripts/release/download-gh-artifacts.sh

Yup, that's what i was wondering, if we'd need to explicitly download them or run this script on a dir that already contains them somehow.

I'll need to add that one too right ?

@hasufell
Copy link
Member

The other option is to run it in CI, but that's not worth it imo. One has to download the artifacts either way to upload them to downloads.haskell.org. I don't think haskell infra allows automatic uploads through machine keys (I hope they don't), so it's a manual step.

@arjunkathuria
Copy link
Contributor Author

I see.
Since we don't seem to do github binary releases for cabal-install, i suppose i'd have to download them from upstream links like https://downloads.haskell.org/~cabal/cabal-install-3.10.1.0/ ?

@arjunkathuria
Copy link
Contributor Author

arjunkathuria commented Nov 11, 2023

Added the script to download the binary release files on a release number basis and verify the downloaded checksums on them. To be used in conjunction with the GHCup metadata generating script.


## Download release files
echo "Downloading form: \"https://downloads.haskell.org/~cabal/cabal-install-${RELEASE}/\""
wget --no-parent -r --reject "index.html*" --no-directories "https://downloads.haskell.org/~cabal/cabal-install-${RELEASE}/"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the wrong way around and would mean we download twice: once manually and once after we uploaded (why?).

The artifacts are built on gitlab CI. The release manager will have to download them to their local machine in order to upload them to downloads.haskell.org. And they want to perform the yaml step after they downloaded from gitlab, not after they uploaded to the download server.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Since we don't seem to do github binary releases for cabal-install, i suppose i'd have to download them from upstream links like https://downloads.haskell.org/~cabal/cabal-install-3.10.1.0/ ?

could've mentioned here when i asked to confirm.

What's the correct url here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chreekat might know

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🕯️ * summons @chreekat * 🕯️

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👻

Copy link
Contributor Author

@arjunkathuria arjunkathuria Nov 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think that this is better suited as its own issue/PR pair?
The scope of this particular PR was to make a script that generates metadata for GHCup for a cabal release.

I think we can iterate on the how-to and where-to download parts that make releases easier as its own rel-eng issue as it would evolve into its own discussion/interface requirements.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're asking for the URL to download artifacts from gitlab.

That's why I suggest talking to a past/current Cabal release manager. I imagine they already have a workflow for this. While I can point to release pipelines and explain in general how to find the artifacts, it would be better to know what the actual current process is. Maybe @Kleidukos can help.

Do you think that this is better suited as its own issue/PR pair?
The scope of this particular PR was to make a script that generates metadata for GHCup for a cabal release.

Yeah, I totally agree with that.

To actually automate it, it would be a lot easier to run the script in the GitLab pipeline that generates the bindists in the first place. That's what I can help with. https://github.com/haskell/cabal/blob/master/.gitlab-ci.yml is the entrypoint.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the best course of action is to purge gitlab CI.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

@arjunkathuria arjunkathuria Nov 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, they do it in a couple of steps.

  1. get the job ids from a pipeline id.
  2. try to get artifacts from these job ids and error if anyone of those failed.
  3. If successful, generate metadata from these artifacts.

step 3. is mostly done here.

i suppose i can try repurposing the logic in steps 1. and 2. from their python scripts in the shell script here.
If that's not required or if that needs to be a separate issue/PR pair or a broader discussion, please do let me know.

@hasufell
Copy link
Member

I migrated release CI to github and also added the yaml snippet and download scripts. That makes this PR obsolete.

#9437

@Mikolaj
Copy link
Member

Mikolaj commented Nov 13, 2023

You mean, "obsolete in the future"? That's what all PRs are. :)

I'm guessing (@Kleidukos, correct me if I'm wrong), in the best case, we'd migrate to exclusively github for release after a couple of release using both gitlab and github and fine-tuning the new (github) method. For these couple of releases, this PR is still likely to be a great help (and possibly for the fine-tuning).

Still, it's fair heads-up to @arjunkathuria, in case this PR needs a lot of work still and, presumably, it's life-span would be shorter than initially expected. So, @arjunkathuria, it's your call and, in any case, the work you spent on that is very much appreciated.

@arjunkathuria
Copy link
Contributor Author

arjunkathuria commented Nov 13, 2023

Thanks @Mikolaj

Ah well.
This PR is ready if we download from download.haskell.org and just want to generate the GHCup metadata, which i believe was the original scope.

I'd be alright to close this when #9437 gets merged, as it probably supersedes this.

I'd like to thank everyone involved @Mikolaj @hasufell @Kleidukos @chreekat @ulysses4ever and @Bodigrim for their time and effort put into providing great feedback and reviewing this.

@arjunkathuria
Copy link
Contributor Author

just looked at #9437 to find that @hasufell closed it? unsure where this leaves this PR, any inputs @Mikolaj @Kleidukos @hasufell ?

i'd be pretty alright to close this if the script isn't required/useful anymore or if the underlying assumptions and scope changed.

@hasufell
Copy link
Member

just looked at #9437 to find that @hasufell closed it? unsure where this leaves this PR, any inputs @Mikolaj @Kleidukos @hasufell ?

i'd be pretty alright to close this if the script isn't required/useful anymore or if the underlying assumptions and scope changed.

I won't be using the bindists from cabal CI for ghcup, except for the ghcup-vanilla-0.0.8.yaml channel, which is still up to upstream to contribute. So your script may still be useful for cabal devs.

@Mikolaj
Copy link
Member

Mikolaj commented Nov 17, 2023

@arjunkathuria: It seems we are going to have many releases soon, so your script is likely to be very useful, but the current release manager (@Kleidukos) would know best.

@arjunkathuria arjunkathuria changed the title [Rel-Eng] [Draft]: Adds script to automatically generate GHCup metadata for Cabal releases [Rel-Eng]: Adds script to automatically generate GHCup metadata for Cabal releases Nov 27, 2023
@arjunkathuria
Copy link
Contributor Author

Bump.

cc: @Kleidukos

@Kleidukos
Copy link
Member

Ok let's bring this in.
@arjunkathuria Thanks again for this work, this is going to be most valuable.

@Kleidukos Kleidukos added the squash+merge me Tell Mergify Bot to squash-merge label Dec 1, 2023
@Kleidukos Kleidukos removed the squash+merge me Tell Mergify Bot to squash-merge label Dec 1, 2023
Copy link
Member

@Mikolaj Mikolaj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will, obviously, be refined on actual usage, but that's a solid start at least. Thank you!

@Mikolaj Mikolaj added the squash+merge me Tell Mergify Bot to squash-merge label Dec 1, 2023
@Mikolaj
Copy link
Member

Mikolaj commented Dec 1, 2023

[BTW, I haven't informed the git police yet, but the convention is that commit messages are sentences in imperative present tense without the ending dot ("Tweak wibbles in fobuscator").]

@Mikolaj
Copy link
Member

Mikolaj commented Dec 1, 2023

CI seems stuck. A rebase would probably help.

@arjunkathuria
Copy link
Contributor Author

[BTW, I haven't informed the git police yet, but the convention is that commit messages are sentences in imperative present tense without the ending dot ("Tweak wibbles in fobuscator").]

updated the commit messages as suggested, thanks!

A rebase would probably help.

Done, rebased to latest master

Ok let's bring this in.
@arjunkathuria Thanks again for this work, this is going to be most valuable

but that's a solid start at least. Thank you!

That's quite encouraging. Thanks again, for all your time and feedback on this @Kleidukos @Mikolaj !

@mergify mergify bot added the merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days label Dec 3, 2023
@Mikolaj
Copy link
Member

Mikolaj commented Dec 15, 2023

@arjunkathuria: could you mark this PR as "Maintainers are allowed to edit this pull request. " so that mergify can rebase and merge it? Let me know if that's problematic.

@arjunkathuria
Copy link
Contributor Author

arjunkathuria commented Dec 15, 2023

Hi @Mikolaj, hope you've been well.

Let me know if that's problematic.

Hardly, Done!
I just rebased to latest to save you some time : D

Adds the initial version of the release script that generates
the metadata for a given release automatically in the correct format
which can be used by GHCup as-is which makes it way easier to add
that release to be distributed via GHCup.

This would evolve based on the feedback from the maintainers but
the basic core functionality still works.

To Resolve: haskell#9298
Modifies the top shebang from being #!/bin/bash to #!/usr/bin/env bash
as requested in the PR review
The script to generate GHCup metadata needs the artifacts already downloaded.
This script was made to be used in conjunction to the ghcup metadata generating
script.

This script:-

* Makes the directories that ./create-release-metadata-for-ghcup.sh CDs into
* Downloads the binary release files given a particular release number into
  correct directories.
* Verifies that the downloaded checksums match the expected values upstream.
… metadata generating script

Checks if binary-release folders for the release passed exist.
"create-release-metadata-for-ghcup.sh" needs the release files pre-downloaded.

Echos user to run the download script first if correct binaries folder not
found.
We do not want to commit the downloaded binary files for a cabal release.
This prevents us from doing that, even on accident.
…load script

Modifies the top shebang from being #!/bin/bash to #!/usr/bin/env bash
in the 'download-cabal-install-release-binaries.sh'

The later seems more portable as learned from the PR review comments.
@mergify mergify bot merged commit 699df5d into haskell:master Dec 16, 2023
48 checks passed
@Mikolaj
Copy link
Member

Mikolaj commented Dec 16, 2023

Great. That was enough for mergify. Thank you again for your contribution!

Kleidukos pushed a commit that referenced this pull request Mar 19, 2024
…abal releases (#9411)

* [Rel-Eng]: Add initial version of the release metadata script

Adds the initial version of the release script that generates
the metadata for a given release automatically in the correct format
which can be used by GHCup as-is which makes it way easier to add
that release to be distributed via GHCup.

This would evolve based on the feedback from the maintainers but
the basic core functionality still works.

To Resolve: #9298

* [Rel-Eng]: Change top shebang from '/bin/bash' to '/usr/bin/env bash'

Modifies the top shebang from being #!/bin/bash to #!/usr/bin/env bash
as requested in the PR review

* [Rel-Eng]: Add script to download cabal-install binaries for a release

The script to generate GHCup metadata needs the artifacts already downloaded.
This script was made to be used in conjunction to the ghcup metadata generating
script.

This script:-

* Makes the directories that ./create-release-metadata-for-ghcup.sh CDs into
* Downloads the binary release files given a particular release number into
  correct directories.
* Verifies that the downloaded checksums match the expected values upstream.

* [Rel-Eng]: Integrate the release binary downloading script into GHCup metadata generating script

Checks if binary-release folders for the release passed exist.
"create-release-metadata-for-ghcup.sh" needs the release files pre-downloaded.

Echos user to run the download script first if correct binaries folder not
found.

* [Rel-Eng]: Add release-scripts binary-downloads to gitignore

We do not want to commit the downloaded binary files for a cabal release.
This prevents us from doing that, even on accident.

* [Rel-Eng]: Change from '/bin/bash' to '/usr/bin/env bash' in the download script

Modifies the top shebang from being #!/bin/bash to #!/usr/bin/env bash
in the 'download-cabal-install-release-binaries.sh'

The later seems more portable as learned from the PR review comments.
erikd pushed a commit to erikd/cabal that referenced this pull request Apr 22, 2024
…abal releases (haskell#9411)

* [Rel-Eng]: Add initial version of the release metadata script

Adds the initial version of the release script that generates
the metadata for a given release automatically in the correct format
which can be used by GHCup as-is which makes it way easier to add
that release to be distributed via GHCup.

This would evolve based on the feedback from the maintainers but
the basic core functionality still works.

To Resolve: haskell#9298

* [Rel-Eng]: Change top shebang from '/bin/bash' to '/usr/bin/env bash'

Modifies the top shebang from being #!/bin/bash to #!/usr/bin/env bash
as requested in the PR review

* [Rel-Eng]: Add script to download cabal-install binaries for a release

The script to generate GHCup metadata needs the artifacts already downloaded.
This script was made to be used in conjunction to the ghcup metadata generating
script.

This script:-

* Makes the directories that ./create-release-metadata-for-ghcup.sh CDs into
* Downloads the binary release files given a particular release number into
  correct directories.
* Verifies that the downloaded checksums match the expected values upstream.

* [Rel-Eng]: Integrate the release binary downloading script into GHCup metadata generating script

Checks if binary-release folders for the release passed exist.
"create-release-metadata-for-ghcup.sh" needs the release files pre-downloaded.

Echos user to run the download script first if correct binaries folder not
found.

* [Rel-Eng]: Add release-scripts binary-downloads to gitignore

We do not want to commit the downloaded binary files for a cabal release.
This prevents us from doing that, even on accident.

* [Rel-Eng]: Change from '/bin/bash' to '/usr/bin/env bash' in the download script

Modifies the top shebang from being #!/bin/bash to #!/usr/bin/env bash
in the 'download-cabal-install-release-binaries.sh'

The later seems more portable as learned from the PR review comments.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
attention: needs-review merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days squash+merge me Tell Mergify Bot to squash-merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants