Skip to content

Bootstrapping on a self-hosted server

Dear @DarwinJS

This is not so much an issue than a recommendation.

First I thank you for developing so many of these GitLab CI Components. The scope of this issue is the interdependence of ci-component-pub, ultimate-auto-semver and kaniko I must say the effort to bring the code in-house on a self-hosted instance was much harder than I initially expected. I forked these repos to my corporate self-serve instance.

  1. I was not able to create a new top-level group called guided-explorations So it moved into a new PATH relative to the server URL
  2. The use of $CI_SERVER_FQDN is not support in my self-hosted 16.x release of GitLab. I had to change all those references to CI_SERVER_HOST
  3. Getting the Components bootstrapped was simply impossible until I replaced the include:component to include:project elements, get the initial components built , then slowly step-by step reverted back to the include:component methodology.
  4. This is particularly difficult in 16.x which does not allow me to use selectors like @2.2 meaning any patch release which starts with 2.2 This appears to be a feature in 17+
  5. The circular dependencies between the components is impossible to maintain. There will always be a newer release of ci-components-pub than what the other two components list as dependencies.
  6. If I do development on these clones using a feature branch merges into main model, (versus Fast-Forward) then it gets even worse. New versions are created during the merge back to main.
  7. When I work self-hosted, I end up creating a number of releases which you have not used yet. If I wan to update my fork from your original, I will have conflicts with the tags
  8. For some reason the substitution of _UPDATE_DURING_COMPONENT_PUBLISH_ with the version stringis not working for me at all and I had to fix it to deal with the possibility of a complex component which has more than a single YML file per component
  9. I do not for the life of me understand what is the value-add of kaniko in this pipeline. What part of the pipeline need the creation of custom dockerimages?
  10. Perhaps it would be simpler to have ci-component-pub includes the other two components source code as Git submodules and in the build phase, populate the templates directory with the union of all the other required components.
  11. maybe when the ci-component-pub .gitlab-ci.yml file uses include:component it could use @$CI_COMMIT_SHA as the version specifier for itself instead of a version number?

I have spend 2-3 days on this on trying to get this to work. I do have something working, but the remaining circular dependencies still haunts me as foolish.

Best Regards Sam Nuwayser

Edited by Sami Nuwayser