Running jx boot in an empty folder with a clean cluster context results in an immediate error:
➜ jx boot
WARNING: there was a problem obtaining the boot config repository git configuration, falling back to defaults. Error: there was a problem obtaining the remote Git URL of directory .: failed to unmarshal due to no GitConfDir defined
No Jenkins X pipeline file jenkins-x.yml or no jx boot requirements file jx-requirements.yml found. You are not running this command from inside a Jenkins X Boot git clone
? A local Jenkins X versions repository already exists, pulling the latest: Yes
error: failed to create version resolver: : pulling the latest: non-fast-forward update
Previously, this would bootstrap itself by installing whatever was necessary.
The output of jx version is:
2.0.905
The problem can be worked around by deleting ~/.jx/environments/
We seem to be back to the age-old problem of developers presupposing that there will only ever be one cluster associated with one instance of a workstation. I would suggest that it is essential that the architecture make it explicit that this is always going to be a many-to-many relationship in practice. A single user may be maintaining many clusters and many users may be jointly responsible for maintaining individual cluster instances.
All local caching must be isolated under a tree structure that respects the individual kubernetes context or project/cluster name. Note that cluster-name is only unique within the scope of a project and a user can be expected to participate in multiple projects.
also "jx context" , which switches the context, switches context "globally" - all open terminals get the same context. Which can be a little surprising when you believe you are working on separate clusters.
Not exist "~/.jx/environments/"
$ ls ~/.jx
bin debug draft jenkins-x-versions
jx boot does not work for me, too. It prints a warning and eats 100% CPU then, until it is terminated (CTRL-C)
PS C:\dev\jx> jx --version
2.0.1116
PS C:\dev\jx> jx boot
WARNING: there was a problem obtaining the boot config repository git configuration, falling back to defaults. Error: there was a problem obtaining the remote Git URL of directory .: failed to unmarshal due to no GitConfDir defined
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://jenkins-x.io/community.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://jenkins-x.io/community.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://jenkins-x.io/community.
/close
@jenkins-x-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten.
Provide feedback via https://jenkins-x.io/community.
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository.
Most helpful comment
The problem can be worked around by deleting ~/.jx/environments/
We seem to be back to the age-old problem of developers presupposing that there will only ever be one cluster associated with one instance of a workstation. I would suggest that it is essential that the architecture make it explicit that this is always going to be a many-to-many relationship in practice. A single user may be maintaining many clusters and many users may be jointly responsible for maintaining individual cluster instances.
All local caching must be isolated under a tree structure that respects the individual kubernetes context or project/cluster name. Note that cluster-name is only unique within the scope of a project and a user can be expected to participate in multiple projects.