search

alshedivat / al-folio

A beautiful, simple, clean, and responsive Jekyll theme for academics
https://alshedivat.github.io/al-folio/
MIT License
11.34k stars 11.28k forks source link

Additional instructions for Apple Silicon Users #2705

Open 0xAdriaTorralba opened 2 months ago

0xAdriaTorralba commented 2 months ago

Trying to deal with building the website using Github Actions, I found a problem related to my local development build being an Apple Silicon Mac.

I found a workaround for this, and I'm sharing and adding the step-by-step to fix the problem, in case you find suitable to include this for the rest of Apple Silicon Mac users :)

george-gca commented 2 months ago

Can you verify this @pourmand1376? I don't have access to a Mac.

pourmand1376 commented 2 months ago

Hey Guys.

I tested on M1 Mac and I really couldn't figure out the issue.

Here's what I've done. 

docker compose pull
docker compose up

Is there any way to replicate your issue?

0xAdriaTorralba commented 2 months ago

The issue is not related to local development, but when you try to deploy this website to Github Actions, see here an instance of a failed build when you push your changes from local.

Again, local development is just fine using the docker compose.

george-gca commented 2 months ago

Maybe this is related to #2682, #2544?

pourmand1376 commented 2 months ago

Maybe. I just don't understand why Gemfile is updated in @0xAdriaTorralba repository.

pourmand1376 commented 2 months ago

Can you explain how you updated your Gemfile.lock file and what was the reason?

0xAdriaTorralba commented 2 months ago

Maybe this is related to #2682, #2544?

Yes, it seems so. I got those issues before updaing the Gemfile.lock

Can you explain how you updated your Gemfile.lock file and what was the reason?

The way I managed to update the Gemfile.lock is by doing the step-by-step I added on INSTALL.md, I paste this again here:

  1. Connect to your docker container (docker exec -it <container_name> sh)
  2. Run the following commands inside the container 
    bundle lock --add-platform ruby
bundle lock --add-platform x86_64-linux
  3. Remove Gemfile.lock outside the container (rm -rf Gemfile.lock)
  4. Run bundle install inside the container.
  5. After that, you should have a new Gemfile.lock capable of handling builds for both local and production environments.
  6. Push the new Gemfile.lock and you should be good to go.

The problem here is the following: the first time you run docker compose pull; docker compose up it is populated using the LOCAL development environment, so, it lists and adds the proper items to Gemfile.lock for THAT (local) platform (in my case, ARM-based ones). HOWEVER, it may be the case that the PRODUCTION environment architecture is DIFFERENT from your local one (this is my case, and also the cases on issues #2682, #2554). In this case, you need to rebundle the Gemfile.lock to consider this platform target. Is it clear now?

george-gca commented 2 months ago

Somehow its Gemfile.lock is apparently being overwritten and commited to the repo, which I believe it shouldn't. We have Gemfile.lock versioned here and also added to the .gitignore. Also if you look at the versioned Gemfile.lock we have

https://github.com/alshedivat/al-folio/blob/046545983f0864b62e883105955717cbf298561c/Gemfile.lock#L215

which is the version you just locked into.

pourmand1376 commented 2 months ago

@0xAdriaTorralba

OK. Thanks for explanation. I think a better workaround is that you don't commit Gemfile.lock to the repository and it remains the same instead of changing it everytime. Does that solve your problem?

For that before any commit do this:

git restore Gemfile.lock

@george-gca And About .gitignore. Adding a file to gitignore won't work if we already have that file tracked in repository.

pourmand1376 commented 2 months ago

Thanks for mentioning that. I think we need to add another PR or change this PR somehow to make that change everytime.

We should add this command somewhere to be run after finishing local deployment:

git restore Gemfile.lock

@0xAdriaTorralba. I created another PR to see if I can solve this issue. #2707. I'll see what I can do (I can even add my changes to this PR if you want).

Thanks for bringing our attention to this bug.

george-gca commented 2 months ago

Maybe we should do something like git update-index --assume-unchanged somewhere? Idk if it would solve the issue, since this flag can't be pushed to the repo.

pourmand1376 commented 2 months ago

I merged my change. It should solve this problem.