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

script: previous_release.sh rewritten in python #19205

Merged
merged 2 commits into from
Jul 21, 2020

Conversation

bliotti
Copy link
Contributor

@bliotti bliotti commented Jun 8, 2020

Closes #18132

Added functionality:

  1. checks file hash before untarring when using the binary download option

Copy link
Member

@Sjors Sjors left a comment

Choose a reason for hiding this comment

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

Concept ACK, thanks for working on this. 6e4a07c works on macOS 10.15.4 for the standard set of binaries we download, release candidates, and for compiling v0.20.0.

Can you squash your commits?

You can also remove previous_release.sh and switch over to this Python version (in a separate commit).

Are you using Python 3.5.6? (pyenv should do that automatically)

If you check the checksums then it makes sense to also check their PGP signature. Alternatively we might as well hard code the checksum for each tar.gz release in the source code, here. That way Travis might catch someone messing with bitcoincore.org.

I initially added -f Configure for functional tests as a way to opt-out of building QT. Looking at it again, I think we shouldn't build QT period. So I added inline suggestions to drop QT everywhere.

contrib/devtools/previous-release.py Outdated Show resolved Hide resolved
contrib/devtools/previous-release.py Outdated Show resolved Hide resolved
contrib/devtools/previous-release.py Outdated Show resolved Hide resolved
contrib/devtools/previous-release.py Outdated Show resolved Hide resolved
contrib/devtools/previous-release.py Outdated Show resolved Hide resolved
@practicalswift
Copy link
Contributor

Concept ACK

Nice first-time contribution @bliotti - welcome as a contributor! :)

@bliotti
Copy link
Contributor Author

bliotti commented Jun 8, 2020

Thanks, I have always wanted to contribute! I will follow up with the mentioned suggestions. :)

@bliotti
Copy link
Contributor Author

bliotti commented Jun 8, 2020

Concept ACK, thanks for working on this. 6e4a07c works on macOS 10.15.4 for the standard set of binaries we download, release candidates, and for compiling v0.20.0.

Can you squash your commits?

You can also remove previous_release.sh and switch over to this Python version (in a separate commit).

Are you using Python 3.5.6? (pyenv should do that automatically)

If you check the checksums then it makes sense to also check their PGP signature. Alternatively we might as well hard code the checksum for each tar.gz release in the source code, here. That way Travis might catch someone messing with bitcoincore.org.

I initially added -f Configure for functional tests as a way to opt-out of building QT. Looking at it again, I think we shouldn't build QT period. So I added inline suggestions to drop QT everywhere.

Yes I will squash my commits.

Just to confirm, I need to squash all these commits into one commit that encompasses the addition of the py script, and then... push up one more commit for the removal of the bash script.

Most of the suggestions have been incorporated I just need to add the PGP signature check and I should have it up soon.

Copy link
Member

@Sjors Sjors left a comment

Choose a reason for hiding this comment

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

I restarted Travis for an unrelated failure (details in #19221)

It's probably better to move closes #18132 into the commit message body instead of the subject (needs a blank line). Title could be: test: switch usage of previous_release.sh to .py . Right now the changes are mixed between both commits; a single commit is fine too if it's tricky to untangle.

Let's not download and add PGP keys on behalf on the user. You could check if the key is present and fail otherwise.

contrib/devtools/previous-release.py Outdated Show resolved Hide resolved
contrib/devtools/previous-release.py Outdated Show resolved Hide resolved
@fjahr
Copy link
Contributor

fjahr commented Jun 18, 2020

Concept ACK

Great first contribution @bliotti! I will take a closer look one you have squashed the commits. You can make yourself a co-author as well, I think. And I think @Sjors mistyped, it should be script: ....

@bliotti bliotti force-pushed the previous-release-py branch 4 times, most recently from a93248f to 60faac3 Compare July 2, 2020 08:25
Copy link
Contributor

@fjahr fjahr left a comment

Choose a reason for hiding this comment

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

tested ACK 60faac3

However, the docs should be updated. CI failure seems to be unrelated. I could restart Appveyor but it seems I can't restart that Travis build.

Also, the formatting changes in the second commit make this a longer review than necessary and I think many of them are not worth the noise they create. In some cases, the original authors even made an effort to line up comments etc. I don't use that style but it's not necessary to remove it unless you are editing that particular part of the file. For me, it's ok to keep them but other reviewers might disagree. If you keep them they should be moved into their own commit so that their current commit does what the commit message says: script: removed previous_release.sh. I would suggest to make it:

script: switch previous_release from .sh to .py version

Remove previous_release.sh

(the switch is more significant than the removal of the file).

And then the formatting changes move to refactor: Clean up functional compat test formatting.

EDIT: actually, the first commit message should be changed as well then because it doesn't do the switch now. Should be just something like script: Add previous_release.py.

test/functional/wallet_upgradewallet.py Outdated Show resolved Hide resolved
contrib/devtools/previous-release.py Outdated Show resolved Hide resolved
@DrahtBot
Copy link
Contributor

DrahtBot commented Jul 2, 2020

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

contrib/devtools/previous_release.py Outdated Show resolved Hide resolved
contrib/devtools/previous_release.py Outdated Show resolved Hide resolved
@fjahr
Copy link
Contributor

fjahr commented Jul 4, 2020

I think for the "co-authored-by:" to work as intended it needs to be at the end of the commit message. You can check that it shows both profile pictures and in Github it says 'bliotti and bboot committed'. You also only need to list the additional co-authors, not the author of the commit itself (yourself in this case).

See 4950e5d (#19055) for example.

bliotti and others added 2 commits July 5, 2020 04:04
closes bitcoin#18132
added GPG verify for binaries

co-authored-by: bboot <bboot@cisco.com>
@fjahr
Copy link
Contributor

fjahr commented Jul 5, 2020

re-ACK 9c34aff

Side-note: Waiting for author label can be removed.

@bliotti
Copy link
Contributor Author

bliotti commented Jul 5, 2020

thanks for the help @fjahr 👍

@Sjors
Copy link
Member

Sjors commented Jul 9, 2020

tACK 9c34aff

@bliotti
Copy link
Contributor Author

bliotti commented Jul 20, 2020

Is there anything I need to do now?

@fjahr
Copy link
Contributor

fjahr commented Jul 20, 2020

Is there anything I need to do now?

Not really, but you could respectfully ping someone to get another review/ACK. With three ACKs this should be ready for merge and if maintainers don't take notice then you could post a message in IRC that this might be RFM after a few days.

@jonatack
Copy link
Member

Is there anything I need to do now?

@bliotti welcome! May I suggest this section (particularly the last item) https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#finding-reviewers, followed by these steps:

@emsheets
Copy link

Concept ACK, will test later today if test ACKs still needed at that time. Great stuff, @bliotti!!

@maflcko maflcko merged commit ea595d3 into bitcoin:master Jul 21, 2020
@maflcko
Copy link
Member

maflcko commented Jul 21, 2020

I did some minor cleanups in #19560

sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Jul 21, 2020
9c34aff Remove previous_release.sh (Brian Liotti)
e1e5960 script: Add previous_release.py (Brian Liotti)

Pull request description:

  Closes bitcoin#18132

  Added functionality:
  1) checks file hash before untarring when using the binary download option

ACKs for top commit:
  fjahr:
    re-ACK 9c34aff
  Sjors:
    tACK 9c34aff

Tree-SHA512: 323f11828736a372a47f048592de8b027ddcd75b38f312dfc73f7b495d1e078bfeb384d9cdf434b3e70f2c6c0ce2da2df48e9a6460ac0e1967c6829a411c52d5
@bliotti
Copy link
Contributor Author

bliotti commented Jul 21, 2020

I did some minor cleanups in #19560

Thanks! @MarcoFalke

@hebasto
Copy link
Member

hebasto commented Aug 26, 2020

Alternatively we might as well hard code the checksum for each tar.gz release in the source code, here. That way Travis might catch someone messing with bitcoincore.org.

Please see #19813.

maflcko pushed a commit to bitcoin-core/gui that referenced this pull request Aug 31, 2020
0374e82 util: Hard code previous release tarball checksums (Hennadii Stepanov)
bd897ce scripted-diff: Move previous_release.py to test/get_previous_releases.py (Hennadii Stepanov)

Pull request description:

  #19205 introduced signature verifying for the downloaded `SHA256SUMS.asc`.
  This approach is brittle and does not work in CI environment for many reasons:
  - bitcoin/bitcoin#19812 (comment)
  - bitcoin/bitcoin#19013 (comment)

  This PR:
  - implements **Sjors**' [idea](bitcoin/bitcoin#19205 (review)):
  > Alternatively we might as well hard code the checksum for each `tar.gz` release in the source code, here.

  - is an alternative to 5a2c31e528e6bd60635096f233252f3c717f366d (#19013)

  - fixes #19812

  - updates v0.17.1 to v0.17.2

ACKs for top commit:
  MarcoFalke:
    cr ACK 0374e82
  Sjors:
    tACK 0374e82

Tree-SHA512: cacdcf9f5209eae7da357abb3445585ad2f980920fd5bf75527ce89974d3f531a4cf8b5b35edfc116b23bfdfb45c0437cb14cbc416d76ed2dc5b9e6d33cdad71
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Aug 31, 2020
…cksums

0374e82 util: Hard code previous release tarball checksums (Hennadii Stepanov)
bd897ce scripted-diff: Move previous_release.py to test/get_previous_releases.py (Hennadii Stepanov)

Pull request description:

  bitcoin#19205 introduced signature verifying for the downloaded `SHA256SUMS.asc`.
  This approach is brittle and does not work in CI environment for many reasons:
  - bitcoin#19812 (comment)
  - bitcoin#19013 (comment)

  This PR:
  - implements **Sjors**' [idea](bitcoin#19205 (review)):
  > Alternatively we might as well hard code the checksum for each `tar.gz` release in the source code, here.

  - is an alternative to 5a2c31e (bitcoin#19013)

  - fixes bitcoin#19812

  - updates v0.17.1 to v0.17.2

ACKs for top commit:
  MarcoFalke:
    cr ACK 0374e82
  Sjors:
    tACK 0374e82

Tree-SHA512: cacdcf9f5209eae7da357abb3445585ad2f980920fd5bf75527ce89974d3f531a4cf8b5b35edfc116b23bfdfb45c0437cb14cbc416d76ed2dc5b9e6d33cdad71
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

contrib/devtools/previous_release.sh should be rewritten to python