Comments (13)
I will investigate today and let you know
from build-d8.
I have some good news and some bad news.
- Good news: I can build it successfully using the container made from my repository
- Bad news: I did that accidentally. I meant to do the build from the latest container of this repository and used mine instead. So, now I'm starting a new build to do it starting with the dockerfile here. Since I am able to do it using the other repo I suppose whatever the issue is, should be fixable. I just need to figure it out. I'll update once I know what the fix is.
from build-d8.
Ah actually I used the correct repository: https://github.com/compiler-explorer/d8-builder
So I made a fresh container from the fork that ce uses and I was able to do the build successfully. hmm.. this is strange. So the build is failing in the CI only it would seem. I did the build by starting a bash session inside the container and running the build manually. Let me try to trigger the build using the script build.sh as it would be done in the automated system. Maybe that will reproduce it.
from build-d8.
@mattgodbolt will it be possible to recreate that docker image? I think that will fix the problem. If it does, then I'd like to modify the build script to not do a git pull
which requires it to merge changes (which is the problem here I think) and instead delete local main branch and get the remote one. I can't reproduce this issue locally (inside docker desktop) so far, but Ill keep trying while I wait for your reply.
from build-d8.
@gautam1168 I'll try and work out how to recreate! thanks!
from build-d8.
If it works let me know and I'll open a PR to not do a git pull. If it doesn't work I will still need to reproduce this somehow.
from build-d8.
One way to fix both the docker-recreate issue and the git pull is to put in the docker image itself the SHA of the version to git checkout -- so...
git fetch && git checkout KNOWNGOODSHA
then if we change the SHA it forces the image to rebuild too. Do you know such a checkout that would be appropriate?
from build-d8.
Well we don't know the SHA before we do the fetch. Right now when the trunk build happens we do the following:
git checkout main
git fetch
git pull
And I was thinking we could change it to
git checkout -b temp
git branch -D main
git fetch
git checkout main
This would remove the need for a pull
. But I would like to confirm that this pull
is the cause of the build failures before this change is made.
from build-d8.
Running now: https://github.com/compiler-explorer/compiler-workflows/actions/runs/5664634020 (but I am now afk to go to bed..)
from build-d8.
So it worked. Although in the logs I see there is still a pull. I am not really certain why the old container was failing but the pull is the only thing I can think of. Should I make a PR so that there won't be a git pull
involved as I mentioned before?
Well actually I can think of one more thing. The gclient sync
command only runs when the container is built and that command updates the build tools. The failure was happening in gm.py though and that is not in the depot_tools
. Its in the v8 repository itself. Nevertheless I can add a call to gclient sync
each time a build is done as well.
from build-d8.
So it worked. Although in the logs I see there is still a pull. I am not really certain why the old container was failing but the pull is the only thing I can think of. Should I make a PR so that there won't be a git pull involved as I mentioned before?
I don't really understand I'll be honest: if the build ran OK why change?
gclient in the container
right - the container step is more an "acceleration" I thought? I don't really mind either way: I'm not hugely invested in this other than having it working :)
Thanks!
from build-d8.
I don't really understand I'll be honest: if the build ran OK why change?
I was thinking about how to prevent it from breaking again in the future.
right - the container step is more an "acceleration" I thought? I don't really mind either way: I'm not hugely invested in this other than having it working :)
So the container has this line:
RUN cd ~ && fetch v8 && cd ~/v8 && gclient sync \
&& sed -i 's/${dev_list} snapcraft/${dev_list}/g' build/install-build-deps.sh \
&& cd ~/v8/build && ./install-build-deps.sh && git reset HEAD --hard \
&& chown -R root:root /root/v8
Here the gclient sync
performs an update on the build tools. I think this could possibly have been the reason why rebuilding the container made it work.
If you are comfortable with this for now we could just leave it as it is now. If it breaks again in the future I can make these changes to make it more stable.
from build-d8.
Thanks @gautam1168 - I apprecaiate the context. For now I don't have a strong opinion either way. Much appreciated :)
from build-d8.
Related Issues (1)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from build-d8.