Additional instructions for Apple Silicon Users

[0xAdriaTorralba]

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]

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

[pourmand1376]

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]

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]

Maybe this is related to #2682, #2544?

[pourmand1376]

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

[pourmand1376]

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

[0xAdriaTorralba]

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]

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

al-folio/Gemfile.lock

Line 215 in 0465459

x86_64-linux

which is the version you just locked into.

[pourmand1376]

@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]

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]

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]

I merged my change. It should solve this problem.