Skip to content

build: don't ignore Gemfile.lock for deterministic builds - #829

Closed
dijonkitchen wants to merge 1 commit into
github:masterfrom
dijonkitchen:build-gemfile-lock-determinism
Closed

dijonkitchen wants to merge 1 commit into
github:masterfrom
dijonkitchen:build-gemfile-lock-determinism

Conversation

@dijonkitchen

@dijonkitchen dijonkitchen commented Apr 8, 2022 •

Copy link
Copy Markdown

@dijonkitchen dijonkitchen mentioned this pull request Apr 8, 2022
4 tasks done
@fulldecent

Copy link
Copy Markdown
Contributor

This PR seems to make a failed assertion.

When GitHub Pages builds a website (not talking about GitHub Actions) it does NOT use the Gemfile.lock to find what versions to build with.

It means that GitHub Pages' infrastructure decides which versions of Jekyll/Ruby/... it is running, not you.

This PR does not change that behavior of how GitHub Pages infrastructure works.

So if this is PR is accepted, then the test suite will run against new versions of Jekyll/Ruby/... rather than the version that production uses.

If my understand is correct here, we should NOT merge this PR.

@parkr

parkr commented Sep 18, 2023

Copy link
Copy Markdown
Contributor

RubyGems do not ship with their Gemfile.lock files. The guidance you linked to is for end users. There is no way for an end user to use the Gemfile.lock from a RubyGem.

@dijonkitchen
dijonkitchen deleted the build-gemfile-lock-determinism branch January 18, 2024 02:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants