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

Deployment failed with Gemfile.lock (created by local setup) #2544

Closed
2 tasks done
justinhou95 opened this issue Jul 4, 2024 · 6 comments · Fixed by #2549
Closed
2 tasks done

Deployment failed with Gemfile.lock (created by local setup) #2544

justinhou95 opened this issue Jul 4, 2024 · 6 comments · Fixed by #2549
Assignees
Labels

Comments

@justinhou95
Copy link

justinhou95 commented Jul 4, 2024

Have you checked that your issue isn't already filed?

  • I read through FAQ and searched through the past issues, none of which addressed my issue.
  • Yes, I have checked that this issue isn't already filed.

Bug description

Deployment failed with Gemfile.lock

How to reproduce the bug

  1. Local setup using Docker creates Gemfile.lock
  2. Uploading Gemfile.lock causes error in deployment action

How to solve it

  1. Solved by adding Gemfile.lock into .gitignore

Error messages and logs

bundle install
/opt/hostedtoolcache/Ruby/3.2.2/x64/bin/bundle config --local path /home/runner/work/justinhou95.github.io/justinhou95.github.io/vendor/bundle
/opt/hostedtoolcache/Ruby/3.2.2/x64/bin/bundle config --local deployment true
Cache key: setup-ruby-bundler-cache-v6-ubuntu-22.04-x64-ruby-3.2.2-wd-/home/runner/work/justinhou95.github.io/justinhou95.github.io-with--without--only--Gemfile.lock-03358d48efe98caee97dcb4e12a28f649[26](https://github.com/justinhou95/justinhou95.github.io/actions/runs/9794626471/job/27045011792#step:3:32)5ecc3d62e7fddd6bef7fe0b35c8ce
Cache Size: ~155 MB (162713749 B)
/usr/bin/tar -xf /home/runner/work/_temp/cd43a20f-23d2-49fb-ba6d-763e124ad1f6/cache.tzst -P -C /home/runner/work/justinhou95.github.io/justinhou95.github.io --use-compress-program unzstd
Received 16[27](https://github.com/justinhou95/justinhou95.github.io/actions/runs/9794626471/job/27045011792#step:3:33)13749 of 162713749 (100.0%), 155.0 MBs/sec
Cache restored successfully
Found cache for key: setup-ruby-bundler-cache-v6-ubuntu-22.04-x64-ruby-3.2.2-wd-/home/runner/work/justinhou95.github.io/justinhou95.github.io-with--without--only--Gemfile.lock-02f2f3fb583f91aee8d3bdf99af70[28](https://github.com/justinhou95/justinhou95.github.io/actions/runs/9794626471/job/27045011792#step:3:34)535c7e6e8cbcbd49011b5b1d319db5486
/opt/hostedtoolcache/Ruby/3.2.2/x64/bin/bundle install --jobs 4
Your bundle only supports platforms ["aarch64-linux-gnu"] but your local
platform is x86_64-linux. Add the current platform to the lockfile with
`bundle lock --add-platform x86_64-linux` and try again.
Error: The process '/opt/hostedtoolcache/Ruby/3.2.2/x64/bin/bundle' failed with exit code 16

What operating system are you using?

Not applicable (e.g. you're using GitHub Pages or other hosting)

Where are you seeing the problem on?

Deployed site

More info

No response

@pourmand1376
Copy link
Collaborator

pourmand1376 commented Jul 4, 2024

Hi. @justinhou95

I see your problem. Also, I see here that Gemfile.lock is updated. Is it done automatically?

What is your linux distribution? I see the platform is different.

Does this command help the problem? bundle lock --add-platform x86_64-linux

@pourmand1376
Copy link
Collaborator

It seems that we should add x86_64-linux to existing platforms on Gemfile.lock.

@george-gca
Copy link
Collaborator

If this fixes the problem we could add it to our repo. @justinhou95 any feedback?

@CheariX
Copy link
Contributor

CheariX commented Jul 5, 2024

I have the same problem when running locally on an ARM based macbook. The updated Gemfile.lockdoes not have x86_64-linux, which leads to a failure when deploying on github.

My current solution is to not commit Gemfile.lock, which is suboptimal.

I remember that adding Gemfile.lock was a kind of workaround due to a bug in some of the plugins (I never expirenced that one).
Do we still need this workaround?
I think it is very uncommon to have Gemfile.lock managed in git, is it?

@george-gca
Copy link
Collaborator

I believe the discussion was in #2384.

I think it is very uncommon to have Gemfile.lock managed in git, is it?

Not really. It is even recommended in the bundler docs and rails, for example, include it in their repo. Also I agree with this guy:

The Gemfile.lock should stay in the repository because contributors and developers should be able to fork the project and run it using versions that are guaranteed to work.

@tim-puhlfuerss
Copy link

Hi folks,
I ran into the same problem on my MacBook with the M2 chip. The command mentioned by @pourmand1376 solved it.
I found the solution on StackOverflow.

george-gca pushed a commit that referenced this issue Jul 7, 2024
Fixes #2544 

Generated via:
```
bundle lock --add-platform x86_64-linux
```
HaukeCornell pushed a commit to haukesand/haukesand.github.io that referenced this issue Jul 8, 2024
Fixes alshedivat#2544 

Generated via:
```
bundle lock --add-platform x86_64-linux
```
CalaW added a commit to THU-DA-Robotics/thu-da-robotics.github.io that referenced this issue Jul 9, 2024
* Update README.md (alshedivat#2493)

Added Physics-Morris.github.io to the list of academics.

Co-authored-by: Morris Huang <morris8934@gamil.com>

* Fixed issue with vega

* Fix code blocks not changing to plots and others (alshedivat#2497)

For some unknown reason, all the `document.onreadystatechange = () => {`
checks stopped working. Thankfully, replacing them with
`document.addEventListener("readystatechange", () => {` fixed the
issues.

---------

Signed-off-by: George Araujo <george.gcac@gmail.com>

* fix: remove 'index.html' in pagination (alshedivat#2509)

Currently, on the [blog](https://alshedivat.github.io/al-folio/blog/)
page, clicking "older" and "newer" on the pagination at the bottom
direct you forward to links like `/al-folio/blog/page/2/` and backward
to `/al-folio/blog/`.

However, if you click on the `1`, `2`.. etc buttons, there is a
different behavior. The links now contain an `index.html`. For example,
clicking `2` leads you to `/al-folio/blog/page/2/index.html`. It is the
same content, just with a messier hyper link. Same with clicking `1`,
you are brought to `/al-folio/blog/`.

This fix creates a consistency among the hyper links in pagination.

* Added SRaf.ir to README.md (alshedivat#2510)

Hi, I would be more than happy if I could add my personal website here.

* Support pirsch.io for analytics (alshedivat#2513)

* Fixed external post symbol on search (alshedivat#2515)

Fixes alshedivat#2471

Signed-off-by: George Araujo <george.gcac@gmail.com>

* fix: blog highlighted in nav for child pages (alshedivat#2516)

Currently, in all blog posts, or any child page under /blog, the "blog"
in nav is not highlighted.

In all other child pages for a parent in nav, the parent is highlighted.
For example, in a sub page of projects, projects in nav is highlighted.

This fix creates a consistent behavior for nav and highlights the blog
in nav if in a blog post.

BEFORE:
<img width="1427" alt="image"
src="https://github.com/alshedivat/al-folio/assets/52665298/fc79727c-dc22-4af7-8c16-80efa216ecbc">

AFTER:
<img width="1434" alt="image"
src="https://github.com/alshedivat/al-folio/assets/52665298/6b32e7f9-e421-4b08-b86e-813b20ac058e">

* Support superscripts in bibtex author names (alshedivat#2512)

Implements alshedivat#2511

* Added support for a newsletter (alshedivat#2517)

In reference to idea:
alshedivat#2097
In reference to request:
alshedivat#923 (comment)

Added support to integrate a [loops.so](https://loops.so/) mailing list
into the site.

To use, you need to enable `newsletter` in `_config.yml`. You also must
specify a loops endpoint (although I think any mailing list endpoint can
work), which you can get when you set up a mailing list on loops. More
documentation on loops: [here](https://loops.so/docs/forms/custom-form).

Once that is enabled, the behavior is different depending on how you
specified your footer to behave in `_config.yml`. If `footer_fixed:
true`, then the sign up will appear at the bottom of the about page, as
well as at the bottom of blog posts, if you enable `related_posts`.

If `footer_fixed: false`, then the newsletter signup will be in the
footer (on every page), like it is in on [my
website](https://asboyer.com).

I'm not attached to the placement of the signup, and you can choose to
include it wherever you want with `{% include scripts/newsletter.liquid
%}`. Also if you include positional variables into that, you can choose
how you center the signup. So `{% include scripts/newsletter.liquid
left=true %}` positions the signup bar to the left.

Here are some screenshots below:
## Dark version

![image](https://github.com/alshedivat/al-folio/assets/52665298/af7fdb81-6e5f-47a9-958b-4cb93bba9e8f)

## Light version

![image](https://github.com/alshedivat/al-folio/assets/52665298/927f8bc5-b481-448b-ae5e-6f5b1c613243)
I think the input field color should probably change to maybe be light
for both themes? What do you think? I think the dark background looks
cool, but I don't usually see that done like that on other sites.

## Footer fixed

![image](https://github.com/alshedivat/al-folio/assets/52665298/c52f3dc1-0e45-400e-8b71-eeb00d00cb01)


![image](https://github.com/alshedivat/al-folio/assets/52665298/678a2d45-88ab-4d9a-b8cc-9fc6db26d744)

## Footer not fixed

![image](https://github.com/alshedivat/al-folio/assets/52665298/fd2c0228-2bce-4335-ac3c-5cb20a3307e2)


![image](https://github.com/alshedivat/al-folio/assets/52665298/f594b4f2-67e0-4f2b-a3e8-febd579aaf19)
To clarify, if footer isn't fixed, the email signup will appear on every
page.

---------

Co-authored-by: George <31376482+george-gca@users.noreply.github.com>

* Fixed docker-slim.yml issue

* Add example use of annotation and superscripts in bibtex (alshedivat#2520)

![image](https://github.com/alshedivat/al-folio/assets/33930674/e3018225-df99-4ebf-be18-5811f34fcf4b)

![image](https://github.com/alshedivat/al-folio/assets/33930674/afc6150e-0272-4180-bc5e-4ffbf5079239)

![image](https://github.com/alshedivat/al-folio/assets/33930674/40f88a17-4fba-4423-ab16-62fd37d7c574)

![image](https://github.com/alshedivat/al-folio/assets/33930674/c5cfe480-5df7-4f27-87c7-4883af1471ca)

* Bib changes now trigger build action

* Changes to docker-slim.yml now trigger action

* Changes to deploy-image.yml now trigger action

* Changes to deploy-docker-tag.yml now trigger action

* Update CUSTOMIZE.md for Newsletter support (alshedivat#2521)

In reference to alshedivat#2517 and
alshedivat#2517 (comment)

* Fix Altmetric badge not correctly set when Altmetric id is provided (alshedivat#2522)

To reproduce the bug:

```bibtex
@inproceedings{Vaswani2017AttentionIA,
  title     = {Attention is All you Need},
  author    = {Ashish Vaswani and Noam M. Shazeer and Niki Parmar and Jakob Uszkoreit and Llion Jones and Aidan N. Gomez and Lukasz Kaiser and Illia Polosukhin},
  booktitle = {Neural Information Processing Systems},
  year      = {2017},
  doi       = {10.48550/arXiv.1706.03762},
  altmetric = {21021191}
}
```

The bug is
1. It seems to be some weird property of the liquid template that [line
252-254](https://github.com/alshedivat/al-folio/blob/8d82670ff170f98e7d7ea5434428234a8216d460/_layouts/bib.liquid#L252-L254)
doesn't work at all. According to [this
post](https://stackoverflow.com/questions/59887447/liquid-how-to-assign-the-output-of-an-operator-to-a-variable)
and [this issue](Shopify/liquid#236), liquid
doesn't support assign the output of operator to a variable nor a
ternary operator. So based on my console log, the value of
`entry_has_altmetric_badge` is always a string value of
`entry.altmetric` when altmetric is provided in bibtex.
```liquid
{% assign entry_has_altmetric_badge = entry.altmetric or entry.doi or  entry.eprint or entry.pmid or entry.isbn %}
{% assign entry_has_dimensions_badge = entry.dimensions or entry.doi or entry.pmid %}
{% assign entry_has_google_scholar_badge = entry.google_scholar_id %}
{% if entry_has_altmetric_badge or entry_has_dimensions_badge or entry_has_google_scholar_badge %}
  <div class="badges">
  {% if site.enable_publication_badges.altmetric and entry_has_altmetric_badge %}
    <span
...
```
Note that this could be problematic that a string in liquid is always
evaluated as true as long as it is defined regardless if it is "" or
"false".
[reference](https://shopify.github.io/liquid/basics/truthy-and-falsy/)
2. when altmetric is defined in bibtex, now the order of set attribute
to badge is eprint > doi > altmetric id > pmid > ISBN, and the badge
doesn't work when an arxiv doi is provided.

I think the expected behavior should be
1. as documented in CUSTOMIZE.md, only render the badge when the entry
is set to either "true" or the altmetric id. (It could also implement to
always render the badge whenever doi or other related attribute is set,
and set altmetric to "false" to disable it)
```md
- `altmetric`: Adds an [Altmetric](https://www.altmetric.com/) badge (Note: if DOI is provided just use `true`, otherwise only add the altmetric identifier here - the link is generated automatically)
```
2. if the almetric id is set, use it first.

* Fix repo card heigth for different repo descriptions (alshedivat#2525)

Hello! I had this minor issue on my website and I saw few other people
using this template and having the same issue.

**Brief**
if two repo's in the same row has different number of lines for the
descriptions, heights of the cards will not be the same if we don't
force the number of lines to be displayed.

**Solution**
By looking at [This
issue](anuraghazra/github-readme-stats#2900) I
could see that they solved it by adding an new option,
`description_lines_count`. This was used on the API request in order to
fix the issue.

---

## Issue reproduced:


![before](https://github.com/alshedivat/al-folio/assets/15076325/238931f5-8a0e-45c5-a9bb-e9c6e4c0f04b)

---

## Issue fixed after the commit:


![after](https://github.com/alshedivat/al-folio/assets/15076325/a0e79cdf-fd6a-4765-b21f-279540ae88fe)

* Update README.md

* Add linux x86-64 to Gemfile.lock (alshedivat#2549)

Fixes alshedivat#2544 

Generated via:
```
bundle lock --add-platform x86_64-linux
```

---------

Signed-off-by: George Araujo <george.gcac@gmail.com>
Co-authored-by: Morris Huang <53600226+Physics-Morris@users.noreply.github.com>
Co-authored-by: Morris Huang <morris8934@gamil.com>
Co-authored-by: George <31376482+george-gca@users.noreply.github.com>
Co-authored-by: Andrew Boyer <asboyer@gmail.com>
Co-authored-by: saeedrafieyan <61290778+saeedrafieyan@users.noreply.github.com>
Co-authored-by: ariseus <33930674+garywei944@users.noreply.github.com>
Co-authored-by: Tiago Lobão <tiago.blobao@gmail.com>
Co-authored-by: Maruan <alshedivat@users.noreply.github.com>
Co-authored-by: Amir Pourmand <pourmand1376@gmail.com>
Suraj-Bhor pushed a commit to Suraj-Bhor/suraj-bhor.github.io that referenced this issue Aug 13, 2024
Fixes alshedivat#2544 

Generated via:
```
bundle lock --add-platform x86_64-linux
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants