I am trying to setup spring cloud config server. I see that there are two options for storing properties. Either Git or Native file system. Looks like people are more leaned towards using GIT against Native.
Our project follows trunk based development meaning it does not cut the branch on every release to production.
If we use GIT to read properties, and if someone change the property after deployment, then there is likely that changed property will be read which may create problem in production.
Did anyone faced the issue? How did you solve them?
If your Spring Cloud Git Backend is set to a tag or commit id (and not a branch), any modification should not be read.
This repository implementation maps the {label} parameter of the HTTP resource to a git label (commit id, branch name or tag).
If the git branch or tag name contains a slash ("/"), then the label in the HTTP URL should be specified with the special string "(_)" instead (to avoid ambiguity with other URL paths).
Since a commit id or tag is immustable, that should avoid reading a new content.
Related
For one of our repositories we set "Custom CI configuration path" inside GitLab to a remote gitlab-ci.yml. We want to do this to prevent Developers to change the gitlab-ci.yml file (as protected files are available in EE Premium and up). But except this purpose, the Custom CI configuration path feature should work anyway for Merge Requests.
Being in repo
group1/repo1
we set
.gitlab-ci.yml#group1/repo1-ci
repo1-ci repository exists and ci works correctly when we push to configured branches etc.
For Merge Request functionality GitLab tells us:
Detached merge request pipeline #123 failed for ...
Project group1/repo1-ci not found or access denied!
We added the developers to repo1-ci repo as developers, to be able to read the files. It does not help. Anyway the expectation is, that it is not run with user permissions, so it should simply find the gitlab-ci.yml file.
Any ideas on this?
So our expectations were right an it seems that we have to add one important thing into our considerations:
If a user interacts in the GitLab UI with the Merge Request features and you are using "Custom CI configuration path" for your gitlab-ci.yml file, please ensure
this user needs at least read permissions to that remote file, even if you moved it to another repo on purpose (e.g. use enhanced file protection in PREMIUM/ULTIMATE or push/merge protect the branches for the Developer role)
the user got this permission change applied in a running session
The last part failed for our users, as it worked one day later. Seems that they just continued working from their open merge request page and GitLab checks the accessibility out of this session (using a cookie, token or something which was not updated with the the access to the remote repo/file)
It works!
I started to use spring cloud config and I have a branch for each client. There're configuration properties which are identical between the branches, and I would like not to duplicate them, but storing them in a single file.
Let's assume I have a branch named "my-branch" and it contains this file:
service.properties:
foo=123
In my master branch I have this file:
service.properties:
foo=456
bar=789
I want to query the label "my-branch" and to get this properties:
foo=123
bar=789
How can I achieve that?
From what I investigated - it's not possible when you are using one repository.
You can achieve it by having composite environment and have common properties in another repo, but there is another limitation
When using a composite environment, it is important that all repositories contain the same labels. If you have an environment similar to those in the preceding examples and you request configuration data with the master label but the Subversion repository does not contain a branch called master, the entire request fails.
See: https://cloud.spring.io/spring-cloud-static/spring-cloud-config/2.0.2.RELEASE/single/spring-cloud-config.html#composite-environment-repositories
In your case it's even more complicated because you are using branch per client.
So you will need to create a separate repo for common configuration with lot of branches for each client containing the same configuration.
In case you use one branch - it's easier and works fine, see this answer.
I have a Gerrit project without any dashboards defined. To make the differentiation between multiple projects on the same Gerrit server easier I would like to create a new dashboards for one of the projects.
The official documentation (at least as of v2.13.5-2456) assumes that the necessary branch where the dashboards are to be created already exist, which ist not the case on my installation. As such, the necessary steps for the first dashboard for a project are omitted there.
So the question is: What are the necessary steps to create a first dashboard for a project? Are there any pitfalls? If so, how can they be avoided?
The biggest problem is creating the new meta branch where the dashboards will be housed. For that you need to make sure the user has the following access rights for the reference refs/meta/dashboards/*:
CreateReference
Push
Now check out your project as usual with git clone ssh://<user>#<server>:29418/<path/to/project> (you may want to adjust the port as necessary). You will have the current master branch in your working directory. However, the dashboards branch only works if the only files in it are actual dashboard configurations.
To solve this you have to create a new orphan branch, which does not have any history or files in it. That can be achieved with git checkout --orphan dashboard_local.
On this branch you can create your dashboard configuration with the syntax as documented in the official manual. Commit this file and make sure that no files other than dashboard configurations are in this branch.
Now this branch needs to be pushed to the server. You can use the regular Gerrit syntax here: git push origin HEAD:refs/meta/dashboards/<group>. Using the <group> identifier you can group several dashboards together in the Gerrit Web-UI.
If you made no syntax errors your dashboard should now show up and new dashboards can be added to this existing branch.
Based on:
An explanation of emtpy (orphaned) branches in git
MediaWiki Help on Gerrit dashboard
I am currently working on a flashcard application where decks created by the user act as Git repositories. When a card is created in the app, a new file is committed to the repository, when a card is changed, the file is changed, and when a card is deleted--well, you get the point.
The file format that the application saves to is a gzipped Git repository, so at no point will I ever need to write the repository to disk. How can I best handle treating decks as a Git repository in this way?
Take a look at libgit2. It supports the in-memory git repository scenario and also has bindings to many languages:
https://libgit2.github.com
For example, by using rugged, the ruby binding for libgit2, you could do things like this:
a_backend = Rugged::InMemory::Backend.new(opt1: 'setting', opt2: 'setting')
repo = Rugged::Repository.init_at('repo_name', :bare, backend: a_backend)
I made a Sinatra app, that will be hosted on Heroku, and the source will be up on GitHub. The problem is that i have a file with API keys, that is currently in .gitignore. Is there a way, that I can push my repo to heroku with the key file and exclude the file when pushing to GitHub?
Thanks in advance!
It is possible to maintain a separate branch just for deployment, but it takes much discipline to maintain it properly:
Add a commit to a production branch that adds the config file (git add -f to bybass your excludes).
To update your production branch, merge other branches (e.g. master) into it.
However, you must then never merge your production branch into anything else, or start branches based on any “production commit” (one whose ancestry includes your “add the keys” commit).
An easier path is to adopt Heroku’s custom of using environment variables to communicate your secret values to your instances. See the docs on Configuration and Config Vars:
heroku config:add KEY1=foobar KEY2=frobozz
Then access the values via ENV['KEY1'] and ENV['KEY2'] in your initialization code or wherever you need them. To support your non-Heroku deployments, you could either define the same environment variables or fall back to reading your existing config files if the environment variables do not exist.
The Figaro gem provides a good way to manage this issue. It basically simulates Heroku's environment variable approach locally, and makes it easy to keep your keys in sync between your development environment and Heroku.