Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Providing hash_extra for local_existing_package #124

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

Closed
andormarkus opened this issue Mar 8, 2021 · 8 comments
Closed

Providing hash_extra for local_existing_package #124

andormarkus opened this issue Mar 8, 2021 · 8 comments

Comments

@andormarkus
Copy link

Hi All,

In the current implementation hash_extra is only working when the package in created by this module.
We are compiling our packages in the CI/CD pipeline and the hash of the .zip file keeps changing however the source code does not change.

It would be great if hash_extraor similarly named variable would have effect on the local_existing_package as well.

Implementation could look like this:
source_code_hash = (var.hash_extra != null ? var.hash_extra : local.filename == null ? false : fileexists(local.filename)) && !local.was_missing ? filebase64sha256(local.filename) : null

Thanks,
Andor

@antonbabenko
Copy link
Member

Source code or timestamp is probably changing, too. If it would be the same, the produced zip archive should also be the same.

Could you please show the debug output as described here with DEBUG2 level?

@andormarkus
Copy link
Author

Hi Anton

Source code does not change because I just trigger a second run on CircleCI. Timestamp is manually overwritten find . -exec touch -t 202001010000 {} \; ˜

Screenshot 2021-03-08 at 14 15 03

Step 4282 and 4277 compiled the deployment package.
Screenshot 2021-03-08 at 14 17 03
Screenshot 2021-03-08 at 14 18 22

As you can see the hash of the source code does not changes. However the has of the package is always changing. Im setting every time in the package as well.

Screenshot 2021-03-08 at 14 20 43

The problem is coming from when you make a pip3 install --quiet --no-deps --target . --requirement requirements.txt and the package is not pure python package. If the package contains C code like wrapt package pip will create a .so. This binary file will be always different and causing the shift of hash

This is how I generate packages
Screenshot 2021-03-08 at 14 27 16

@antonbabenko
Copy link
Member

Thanks a lot for the detailed reply, we will take a look at this when one of us has time.

@dpeliss
Copy link

dpeliss commented Apr 28, 2021

It would be great if we have some var to set the source_code_hash.

Currently, I have another tool that uploads the code to s3, so I don't use the upload from this module but the s3_existing_package parameter. In this case, I need to read the hash code from another file that the same tool populates, it's a gitops based deploy.

Without the option to explicitly set the source_code_hash, the code will never be updated, since the s3 keys don't change either.

The issue is quite the opposite that @andormarkus is facing but with the same solution.

@antonbabenko
Copy link
Member

@dpeliss You can set bucket, key, and version_id like in this commented block:

# s3_existing_package = {
# bucket = "humane-bear-bucket"
# key = "builds/506df8bef5a4fb01883cce3673c9ff0ed88fb52e8583410e0cca7980a72211a0.zip"
# version_id = null
# }

@dpeliss
Copy link

dpeliss commented Apr 28, 2021

I'll need to update my buckets to be versioned, but this will do the job, thank you @antonbabenko πŸ€™

@antonbabenko
Copy link
Member

Fixed in #175. Please update the module to use v2.10.0 or newer.

@github-actions
Copy link

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants