Zoltan Kozma
opened 5 months ago
-
After digging into the code of onedev and figured out that it deals a great deal with the token on the cache(which is absolutely not documented anywhere that I could find) I found the hint next to the field that it has something to do with accessing the main branch... so it turns out that branches can not update the cache.... which is understandable but I would like to have them have their own cache I suppose(still working on that). So once the PR is merged it can upload the cache so this is not a bug it is just a bit of a quirky way and a relatively misleading wording of the error message, while having 0 documentation about it really.
So I guess this is now a feedback... Having exhaustive documentation of the build spec would be nice because while generating it from the ui might sound nice, it is not the most convenient workflow for me anyway.
-
Name Previous Value Current Value Type
Bug
Question
-
Name Previous Value Current Value Priority
Major
Minor
-
Previous Value Current Value Not authorized to upload cache after updating to 12.0.4
Not authorized to upload cache
-
OK managed to set up cache with load keys and the cache key and man it works well so far... but why do I need to either create an access token for my account or a build service account with an access token to be able to save a cache object I am still not quite clear on. The docs still do not really help all that much. One has to try and fail and read these mini tutorials, which do not go into much detail anyway... I would rather have a comprehensive list of job steps where there is a focus on each step and all its use-cases are outlined there. I suppose it is a lot of work I appreciate that but it is also a lot of work to figure all this out by trying to cobble together something borderline acceptable from the docs and I am yet to get used to the ui first approach to pipeline development OneDev is going for.
-
Uploaded cache will be shared by all builds of the project (and even child projects as cache will be looked up along the project hierarchy). So builds will not be allowed to do this to prevent cache pollution attack, unless the code is from default branch (which is assumed to be trusted), or an access token with cache upload privilege is configured for it.
The description under the access token also explains this:
Specify a secret whose value is an access token with upload cache permission for above project. Note that this property is not required if upload cache to current or child project and build commit is reachable from default branch
-
Thanks for the update it is very much appreciated.
Addressing your point about the hint next to the field does not explain the whole process of where to go and how to perform this access token procurement is not documented well. It is a bit unexpected and differs from how other ci systems do it.
It is not to say that your aproach is wrong or anything like that. I am merely pointing out that on the page about caching the reasons for its ways of working and how to set up the access token... such as a run down whether service account or principal account.. oauth or not... does it expire what happens if it does... etc.
I had to dig a lot and the docs search as well as the code search seems to be lacking a little bit in places when it does not find stuff that I found in it afterwards by hand.
I could go another round of why you would allow untrusted people to push branches to your repository and not their own fork or if you do why the branches aren't automatically prefixing their cache keys but it is not the point. I went ahead and added the branch name in the cache key and made the master one the load key created a service account and authorized it which I had to find out where and how to do ( and it works beautiful but excuse my ignorance, I did not know the cache setup from a relatively vague hint about this quirky way OneDev goes out of his way to protect master branch cache instead of just shadowing on branch and leaving master cache alone. I thought for example that you might have disk space concerns. I am just saying that some of the where how and why needs a little work in the docs.
There are no docs about the yaml schena versions either the ui keeps updating it if one uses it to click the yaml together... the docs are in fact is so illegible that gemini ai had no chance of getting it right when I ended up asking it about this in my frustration :) It confidently wrote a pipeline wich blew up onedev with a giant stack trace. I had to go and dig and construct the above intricate solution for something as basic as branch cache management.
Best regards,Zoltan Kozma -
This is what I ended up going with
-
I admit that docs need to be improved, and here I am trying to help you understand the cache mechanism.
It is not that default branch can have a cache, while other branches can not. It is only because that default branch is trusted while others are not. This is reasonable, as other branches can be added by external collaborators etc, or even pull requests. With appropriate permission set up, your project can certainly have per-branch cache, by including branch info in cache key.
-
Previous Value Current Value Open
Closed
| Type |
Question
|
| Priority |
Minor
|
| Assignee | |
| Labels |
No labels
|
UPDATE: turns out it was because I was on a branch build. See 1st comment.
Nothing else changed. I pulled the image and restarted OneDev. The build can no longer upload the cache and it does not tell me anything about why. What do I do?
cache-malfunction-12.0.4.txt