If I modify the pod template in UI as suggested in adding-your-own-pod-templates my changes get lost on the node restart (we are running on GKE with preemptive nodes)
Is there another reccomendation how to do that? I tried to update .jx/cloud-environments/env-jx-infra/myvalues.yaml and run jx upgrade platform but that does not seem to work yet. Any chance it will work from jx install?
I am kind of hesistating to re-create my environment. As a last resort I will modify the jenkins-x-pod-templates configmap, which will likely help till the next jx upgrade
we recently fixed jx upgrade platform so that it can work properly with myvalues.yaml files as described here.
there's some docs on how to do this with helm here: https://jenkins-x.io/getting-started/create-custom-builder/
Related
We are running an omnibus version of Gitlab, and need to update to 15.X. However, the instructions state that ElasticSearch must be updated, and that ES is installed separately from GL. From what I am seeing that isn't the case. We did not install ES, instead it appears to have installed with Gitlab as a Ruby gem. Do we still need to update ES manually before the upgrade to GL? Or will it update as a dependency? Any advice here is helpful, we are currently going in circles trying to figure out what needs to happen.
This is only relevant if you have configured the Elasticsearch integration to enable advanced search with Elasticsearch for your GitLab instance. So first check your settings in the admin panel to see if the integration is configured.
If you are not using the integration, then you don't need to worry about updating it and can skip this step for your GitLab upgrade. The ruby elasticsearch gem is just the client library and will be present in any case, so that seems like a red herring for you here.
If you do have the integration configured and are using advanced search, then you must update your ES cluster to 7.x for GitLab 15.0 -- Elasticsearch is NOT bundled with GitLab omnibus or source installations; you must install it (and upgrade it) yourself. From the docs:
Elasticsearch is not included in the Omnibus packages or when you install from source. You must install it separately and ensure you select your version.
I encountered an error in one of our deployments today so i applied a fix to one of the processes and tried again, however the fix was not picked up. I found i had to create a new release. Is there anyway to force octopus to pick up a change if you try to run the current release again?
That's a core concept in Octopus and its as design. Check the Release Snapshots section of the documentation.
You can update the variables for an already-created release, but not the steps.
I saw many posts with this question, but I didn't find the answer so I ask. I upgraded Sonarqube from 4.5 to 5.6 and it works fine, but the quality profiles are empty. I tried to restore one with the backup/restore option but the rules are ignored:
image. Can you help me?
It sounds like you started up your new instance without the code analyzers.
Unfortunately, installing the analyzers now won't restore your profile customizations. You allude to having backup profile files, so you may be able to get them back that way, but you should be aware that you'll lose some rule customizations.
Assuming you backed up your database before the upgrade like the docs tell you to, your best bet is to restore your DB backup to the pre-upgrade state, install the missing code analyzers, then run the database upgrade.
I also faced the same issue with SonarQube 6.4. I was trying to Reload findbugs rules whereas the plugin was not installed. I first installed the plugin for findbug from Admin login - Update screen. After this if we use Create - Reload Profiles option, it works fine.
I'm using Pods in different iOS projects, now I would like to somehow get notified when a new version is released for one of the pods - no matter if via mail, rss feed or whatever. Does such a possibility exist?
A Podfile will generally semantically constrain the allowed versions of a pod (see semantic versioning):
pod 'Bolts', '~> 1.7'
This example would accept versions from 1.7 up to 2.0 excluded.
So the only way to know if there is a new version that fits your project is to run specifically for your repo:
pod outdated
Knowing that, you can script a Jenkins job to check it periodically.
Try https://www.versioneye.com/ . Not sure how well it works though.
We're using composer, satis and SVN to manage our in-house PHP libraries.
We commit changes to SVN trunk during development, then tag versions (following semantic versioning) when they're ready for testing.
Once a library version is tagged, we can use composer as part of our deployment to the testing environment. Following successful testing, we'd then deploy that same version to production.
The issue here, is that once we've tagged a version for testing, we have to be very careful as the newly tagged version will be picked up by composer when preparing the next prod release.
What I'm imagining, is that we'd tag a version as a beta or RC, (eg v1.1RC1) and somehow configure our deployment process such that it will refuse to deploy an RC or beta to production. If a version is tested successfully, we'd re-tag that version as a released version (v1.1RC1 -> v1.1) and release that.
Can this be achieved?
From what you are saying, I understand that you are actually afraid of tagging a new version of a library because that code could actually be used and break that other application, right?
One approach would be to do good testing. I don't see it should be a problem to tag a version of a library. If the tests are all green, there should be no reason not to tag it. This would work even if the tests are basically only "let's see if it works, manually".
Now the second step is to integrate that new version into the application: Run composer update and see if the application is still running, i.e. start all the tests and wait for green.
I guess it might be a good idea to have a separate area where you check out the application, intentionally run composer update to fetch all the newest libraries, run all the tests and report that a) there are updates and b) they work. A developer should then confirm the update, i.e. do it again manually and commit the resulting composer.lock file, or grab the resulting lock file from that update test.
I don't think there is benefit in using non-production release versions. You have to deal with the next version anyways - constantly toggling the minimum stability setting or adding #RC or #beta flags to the version requirements of the library don't really help.