The Duniter-v2s repo has a heavy CI allowing to build Duniter with embeded chainspec and publish an image to Docker Hub (made by @pini ). Elois stopped providing a server for this runner so @poka moved it to Axiom Team server . But seemingly due to obscure tag practices, the CI is broken. @1000i100 to…

Ok, now that the CI is running, it fails for a reason of password: deploy_docker_release_sha (#76660) · Jobs · nodes / rust / Duniter v2S · GitLab Does someone know how to fix it?

This §Variables is only available on § Protected branches or tags . The branch should be named release/* for the variable to be available in the CI.

I’m not confortable with these kind of limitations. As @poka told me, the CI should be here to make the developer’s work easier, but as elois implemented it, they actually make it a nightmare (see Bootstraper une ĞDev and Difficultés avec l'outillage for examples of what an undocumented CI can make …

Without this feature, Docker Hub can be displayed in the CI and stolen by anyone having the right to push on a branch on this repository. I would not take the risk to remove this security feature. One option could be to replace Docker Hub publication with GitLab container registry . The latter does …

Ok, thanks for the explanations. So @poka only needs to rename his branch release/* for the pipeline to pass?

It looks like I arrived after the battle, but if you still need help I’m around. I confirm that release/ and master are the only branches that can access to the dockerhub’s password, and those branches are reserved to “high privileged” (“maintainer”) users for good reason, since we don’t want to li…

It seems the current CI is highly inefficient: each step installs Rust, downloads all the dependencies, rebuilds them from scratch… I think the cache should be kept between non-concurrent pipelines. Cargo is smart enough to rebuild what needs to be rebuilt, and Substrate is already long enough to b…

I gave it a try with these changes , but it seems to take more time because of the size of the cache (around 4GB) to be uploaded and then downloaded. I had jobs taken up to one hour and more.

I do not know a lot about CI in general and for Rust in particular, but I wonder the relevance of the virtual machine approach to run this CI because: building Duniter from scratch is very long (~30 min - 1h) building Rust is very CPU-intensive, one powerful container is preferable than multiple l…

Duniter CI still has an issue: Pipeline · nodes / rust / Duniter v2S · GitLab This step failed: deploy_docker_release_sha (#78591) · Jobs · nodes / rust / Duniter v2S · GitLab with the error Error: Cannot perform an interactive login from a non TTY device Can somebody work to fix it as it preven…

Duniter Forum

Need to fix GitLab CI for Duniter-v2s

Nodes Duniter-v2s

show post in topic

Home
Categories
Guidelines
Terms of Service
Privacy Policy

Powered by Discourse, best viewed with JavaScript enabled