Skip to content

Conversation

@robigan
Copy link

@robigan robigan commented Nov 25, 2022

As the title says, this PR aims to address #26548 by switching the lint CI job from ubuntu's bionic base image which has python 3.6.5 to ubuntu jammy and use pyenv to install the correct python version as dictated in the project's .python-version file.

I have tested this in a VS Code Dev Container to as closely emulate the Cirrus CI Service

Bumps the base image used in the linting task for the cirrus CI service to use jammy instead of bionic
@DrahtBot
Copy link
Contributor

DrahtBot commented Nov 25, 2022

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

Reviews

See the guideline for information on the review process.
A summary of reviews will appear here.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #25797 (build: Add CMake-based build system by hebasto)

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.

@DrahtBot DrahtBot added the Tests label Nov 25, 2022
Copy link
Member

@maflcko maflcko left a comment

Choose a reason for hiding this comment

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

@robigan
Copy link
Author

robigan commented Nov 25, 2022

@MarcoFalke I have addressed the issues in the new commit, and now it follows through with the rest of the testing. Except that the test scripts in the repo seem to error out with git (See attached)
image
I am not going to try to address this issue as it's got to do with the linting scripts themselves which are interacting with Git, and Git throwing an issue. And given that I haven't touched any of that I'll leave it be unless I am missing something which in that case I'll try to remedy the issue that this change causes

@maflcko
Copy link
Member

maflcko commented Nov 25, 2022

Looks like it does OOM

@robigan
Copy link
Author

robigan commented Nov 25, 2022

Just took a look at Deadsnake's PPA. They claim they don't build Python 3.6.15 because it's already built by ubuntu's repos. Yet the files list contains a tar ball for python 3.6.15 for focal fossa release. I'd say it's possible to untar the tar ball into pyenv's version if it all works smoothly. As for ssl, I am not sure, how come does the test ci job use jammy despite the repo's python version being set to python 3.6.15?

@maflcko
Copy link
Member

maflcko commented Nov 25, 2022

I'd guess that maybe python 3.6 supports building on Jammy by now? You may be able to fix the OOM by bumping the memory or by using clang. Though, I think we'll also want to cache the python binary, otherwise too much time is spent on compiling it for every push.

@robigan
Copy link
Author

robigan commented Nov 25, 2022

I'd guess that maybe python 3.6 supports building on Jammy by now? You may be able to fix the OOM by bumping the memory or by using clang. Though, I think we'll also want to cache the python binary, otherwise too much time is spent on compiling it for every push.

Python 3.6.15 with pyenv definitely compiles (at least for me which was in a dev container which is pretty close to a real ubuntu jammy based machine). The issue is caching the builds. I'll try bump the memory and see if that works, I don't think using Clang is possible as it doesn't seem that pyenv supports it, and using a custom script to download python and compile it requires maintenance that I can't assure. Using pyenv makes maintaining way easier and simple.

@robigan
Copy link
Author

robigan commented Nov 25, 2022

I have discovered that it is indeed possible to cache builds. I have added more commits that try to implement this as automagically as possible

@robigan
Copy link
Author

robigan commented Nov 25, 2022

@MarcoFalke The fixes have been implemented. I just don't understand why lint fails despite saying that no issues were found

Edit: I didn't realize it was shell check erroring out. Gonna try to fix this

@robigan
Copy link
Author

robigan commented Nov 25, 2022

It actually works. Finally. @MarcoFalke Sorry for the excessive amount of pings, but feel free to merge this. Lmk if any squashing is necessary

@DrahtBot DrahtBot mentioned this pull request Nov 25, 2022
16 tasks
@hebasto
Copy link
Member

hebasto commented Nov 25, 2022

Lmk if any squashing is necessary

Yes, it is necessary.

robigan and others added 14 commits November 26, 2022 00:18
- Install build environment dependencies for pyenv (https://github.com/pyenv/pyenv#install-python-build-dependencies)
- Curl https://pyenv.run installer and pipe it to bash
- Add pyenv's bin directory to path
- Run pyenv's init script (https://github.com/pyenv/pyenv#set-up-your-shell-environment-for-pyenv)s
- Use pyenv's CLI to install python 3.6.15
- Use python cache in Cirrus
- Use intermediary directory for interacting with Cirrus's caching functions
- Assign more resources to the cirrus task to compile python 3.6.15
add a tr() descriptor example to the help deriveaddresses examples
This was already suggested in the troubleshooting section, but recommending it upfront would prevent the issue in the first place and speed up builds.
They are mentioned in the figure above, but having them in the table makes it easier to (apt) install everything required.
It was introduced in c1ae726, and it
has no longer been used since 1dd8cbf.
This change allows to use the `test-{security,symbol}-check.py` scripts
when building out of source tree with no need to link scripts into the
build directory.
Th build system targets run those scripts from the top source directory.
This:
- Removes previously created env variables
- Adds echo for the copy to cache process
- Uses cp instead of any mv just to be safe
- Removes any comments that are not relevant
@robigan
Copy link
Author

robigan commented Nov 25, 2022

Lmk if any squashing is necessary

Yes, it is necessary.

Now that I have done a destructive action, I start to believe that I can't have squashed those commits in the first place...

@robigan
Copy link
Author

robigan commented Nov 26, 2022

Now that I've slept on it, I think it might convene me to just generate a patch file for the files I have modified, and open up a new PR. As I forgot merging instead of rebasing does this kind of stuff. I'll wait for further comment from you guys

@robigan
Copy link
Author

robigan commented Nov 26, 2022

Yea no I'll do that

@robigan robigan closed this Nov 26, 2022
@robigan robigan deleted the ci-bump branch November 26, 2022 08:21
@bitcoin bitcoin locked and limited conversation to collaborators Nov 26, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants