Closed hogoww closed 1 year ago
Would someone have an insight on how the file system on the CI looks like by any chance? Or a resource ? =]
Sorry, but I have no experience with Iceberg. Maybe @theseion can help?
Actually, I'm okay for the iceberg part, I'm mostly wondering how the file directory looks like. Does smalltalkCi install itself inside the root of the directory to execute the CI on ? Are they in two different directories and path are relative ? Where is the image downloaded ? If no one knows, I'll debug it myself a bit later, I'd just rather not have to look at the code and do prints in the CI ^^.
Well, I use and you can use smalltalkCI locally. That will also allow you to inspect the directory layout etc. I'm not sure what you need for Iceberg but it should be independent from where smalltalkCI is installed.
I do too, but I give it a absolute path to the config file, as explained in the readme. But where the target directory is matters too, and changes a lot !
If you told us more about how you're running SmalltalkCI, that would help. I for instance, have the following directory structure:
git
| \ SmalltalkCI
\ Fuel
Then I run SmalltalkCI with ./run.sh ... ../Fuel/.test.ston
or ../SmalltalkCi/run.sh .test.ston
.
That's the thing, I cannot reproduce it locally. So I am trying to figure out how the CI is organized to try to reproduce it on it. I am currently experimenting on it, and exploring it.
Locally, Iceberg registration works fine !
And to answer my own questions
Does smalltalkCi install itself inside the root of the directory to execute the CI on ?
Still do not know
Are they in two different directories and path are relative ?
The working directory, and base directory are the one of the project.
Not sure whether the .git directory is with though, currently under investigation
The .git directory is correctly in the working directory.
However Iceberg cannot seem to use gitlib
Where is the image downloaded ? Doesn't matter.
What's important was the working directory.
Why does it matter on the CI whether registration fails?
(Sorry if I'm not explaining myself properly) Because the previous PR #580 is rendered useless then. And you cannot use the Iceberg facilities. For me, that's about using resources that are used in my test cases, that are stored in the git repository. Currently I have two different pieces of code. One for my local CI execution, another for my github action CI execution.
Not sure how other people do that ^^"
I'll stop my investigation for tonight. Findings: The error happens in: createRepository addLocalRepository initializePackagesFromRepository headCommit commit commitFromGitCommit:
This results in a failing FFI call. From the initialization of the repository, it looks like the .git (albeit in the right place) does not answer to the libgit library. This is starting to stretch my knowledge quite a bit.
However I learned a lot on SmalltalkCI behavior, so maybe I'll be able to finally find how to fix it. Maybe we should revert the #580 for now, until I'm able to understand it enough to fix it.
@theseion what do you think?
Iceberg was not built for CI's :). I'm just guessing here but I know that Iceberg is a bit quirky about branches, for example, it won't let you use tags or detached commits, only branches. On CI's it's not unusual to ignore branches and just check out the corresponding commit directly, so when Iceberg goes looking for the branch (which it believes must be checked out) it will not find it. A workaround could be to tell Iceberg to check out the branch first (or do that in the CI pipeline before running Pharo).
I don't think we need to revert, your implementation works for local repositories, which is good and it doesn't hurt anybody that registration doesn't work on the CI.
Iceberg was not built for CI's :). I'm just guessing here but I know that Iceberg is a bit quirky about branches, for example, it won't let you use tags or detached commits, only branches. On CI's it's not unusual to ignore branches and just check out the corresponding commit directly, so when Iceberg goes looking for the branch (which it believes must be checked out) it will not find it. A workaround could be to tell Iceberg to check out the branch first (or do that in the CI pipeline before running Pharo).
I completely agree. Iceberg was not build for such things. I'll try out that workaround, thank you :D
I don't think we need to revert, your implementation works for local repositories, which is good and it doesn't hurt anybody that registration doesn't work on the CI.
That is a very good point !
Still continuing investigating when I find the time. The .git directory looks like it's deleted by Checkout@v2 (or v3)
Note that by default, actions/checkout@v3
shallow copies repos (fetches with a depth of 1). You probably want to set fetch-depth: '0'
so that it fetches the entire history.
I had misunderstood those shallow fetch references... Thanks a lot @fniephaus , looks like this is it ! As this is a Pharo specific detail, that affects the yml of each repository, on how the CI should look, I'm planning of doing a PR which will explain this properly for people encountering this error.
Do you think this should go somewhere else?
Pierre
Great! Since this is specific to GitHub Actions, I think it should be documented at https://github.com/hpi-swa/setup-smalltalkCI. Maybe add an Pharo-specific example that explicitly mentions Iceberg (e.g., "Testing a Pharo Image with Iceberg"), and then explain why fetch-depth: '0'
is needed with a comment in the yml?
Will do ! Again, Thanks a lot for the help !
You're welcome, and thank you. :)
552 should have been fixed by #580, but it does not look like it works.
My repository using it cannot register it. Cannot reproduce locally.
Could not register the tested repository with Iceberg. NotFound: object not found - no match for id (52c965127762b54a623559c03e5664988cc7167f)