On google-repo, in init, I can set a branch (-b), a manifest (-m) and a set of optional parts (Manifest groups, -g).
I cannot seem to find much information about the latter:
On an existing clone, how can I check which manifest groups were chosen, and how can I change them?
Doing a wholly new create/init/sync for a new copy is not really a solution.
Related
I have a repo in which I manage Terraformcode for multiple environments.
For example I would have these files:
/terraform/dev/superapp/main.tf
/terraform/prod/superapp/main.tf
In those files, I define the used providers, modules, etc. The versions of those components are identical on dev and prod.
I enabled renovate on that repo and it works almost perfectly.
But renovate will open a PR that updates the versions for e.g. the aws provider or the eks-module in dev and prod in just one PR.
But I would like to have separate PRs for each module, provider, etc and then again separate PRs for dev and prod.
So I would end up with four PRs regarding the aws-provider and the eks-module.
One for each dependency in each environment.
I checked the docs of Renovate, but I could not really find out which parameter would trigger such a behaviour, but I am sure this has to be possible.
Any help is much appreciated.
You can specify the configuration option additionalBranchPrefix to add a prefix to the branch name created by Renovate. By using parentDir or baseDir in the prefix, Renovate will split PRs based on where the package definition is located.
In your case, since the immediate parent directory has the same name (superapp), you would have to use baseDir to take into account the whole path of the file to update.
Adding this configuration in renovate.json should do the trick:
{
"packageRules": [
{
"managers": ["terraform"],
"additionalBranchPrefix": "{{baseDir}}-",
"packagePatterns": [".*"]
}
]
}
As far as I know that is not possible at the moment with renovate.
You could try and include the files/paths one by one, but I do not think that will work.
The part I'm working on is kernel-devsrc, which is in the recipe recipes-kernel.
I want to change one of the source .c files in drivers/usb/serial in kernal-devsrc. From some of the online materials, I need to:
Have my own layer
In the layer, need a recipe with the same name as recipes-kernel (and further more, recipes-kernel/linux)
Add the .bbappend file and patch file.
The problem is: to create a patch file I need to know the 2 git SHAs of before and after the change, but I don't have access to the third party recipes-kernel, how do I get the SHA??
OR, if that is the wrong way to do this, could you point out the right way to do it? Thanks!
NOTE: This is problem is not like this one: How patching works in yocto, which the author has access to the source code (.c and .h files). I DON"T have access to the source code, the yotco kernel I'm working on is from a public git repo, and I am not able to git commit to get the SHA, which is necessary to create the patch file.
So, the way I do it is to use Quilt, follow the steps there then good to go:
https://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#using-a-quilt-workflow
I don't need to know the SHA (though I still don't know why others in my organization end up writing SHAs in the patch files and how did they know the SHAs).
The power of Yocto is precisely that it makes it relatively straightforward to patch any existing recipes, without requiring write access to the upstream project source code or Yocto layer.
As a pre-requisite, the project needs to have its own layer to track the patches. Then, the easiest way it to use devtool. The general idea is to:
Create a local sandbox to patch the project: devtool modify RECIPE_NAME (use the name of the target recipe here). This command will create a temporary workspace and print the path to this workspace.
Move to the temporary workspace, apply the needed patches and commit them one by one.
Once all the desired patches have been applied, use devtool finish RECIPE_NAME CUSTOM_LAYER_NAME to save the chances as clean patch files in a bbappend in the custom layer.
Under the hood, devtool modify initializes a (writable) git repository in the sandbox. When devtool finish is invoked, devtool checks the list of extra-commits and saves them as patch files in a .bbappend in the target layer.
I'd like to omit an app-specific directory from the revision control check done by Origen:
origen rc mods
Is there something similar to a .gitignore?
Yes, you can set the following in config/application.rb:
config.unmanaged_dirs = %w(some_dir some/other/dir .some_hidden_dir)
config.unmanaged_files = %w(some_file some/other_file.blah *.blah)
Paths should be given relative to Origen.root and as this is applied within the origen rc command it should work with any revision control backend. Although, if you are using Git then it is recommended to just use .gitignore, this feature is intended to replicate that feature for lesser RC tools.
See the default list of ignored files/dirs for other examples: https://github.com/Origen-SDK/origen/blob/master/lib/origen/revision_control.rb#L9
How can I change the .eclipse folder in Linux? I tried adding this line:
-Dosgi.configuration.area=/directory/directory1/eclipse/.eclipse
at the top of eclipse.ini but it doesn't work. I've also tried adding it to various other places in the eclipse.ini but still no luck.
Edit
I have added this line:
-Dosgi.configuration.area=file:/directory/directory1/eclipse/.eclipse
immediately below -vmargs. When Eclipse starts, it now reads from the correct .eclipse location and if .eclipse does not exist there, it creates it. Unfortunately, after Eclipse has loaded, another .eclipse folder is created in my home folder and Eclipse then continues to read from that folder. I suspect that my eclipse.ini file is now correct but there is another file I need to change.
The simplest thing to do is probably pass java a different user.home so that all the other myriad of places that derive a location base it off of user.home. So instead of what you have, use this in .ini file:
-Duser.home=/directory/other/here
In addition to .eclipse, you will probably find other directories created in your overridden user.home, such as .p2, .oracle_jre_usage, etc.
Other notes:
-Dosgi.configuration.area is the changes the configuration area for Eclipse, it does not effect user area. You also probably don't want to change that setting away from the default unless you really want multiple configurations (read more below).
Additionally, the normal thing to do would be to use -configuration as an argument to eclipse{.exe} and let eclipse convert it to the appropriate VM argument.
You probably want -user though to override the user area. Have a look at locations in the Eclipse help for more info (quoted below).
However, there are still things that have individual control over their location, such as secure storage, which is controlled by the -eclipse.keyring command line argument.
Locations
The Eclipse runtime defines a number of locations which give
plug-in developers context for reading/storing data and Eclipse users
a control over the scope of data sharing and visibility. Eclipse
defines the following notions of location:
User (-user) {osgi.user.area} [#none, #noDefault, #user.home,
#user.dir, filepath, url]
User locations are specific to, go figure,
users. Typically the user location is based on the value of the Java
user.home system property but this can be overridden. Information such
as user scoped preferences and login information may be found in the
user location.
Install (-install) {osgi.install.area} [#user.home,
#user.dir, filepath, url]
An install location is where Eclipse itself
is installed. In practice this location is the directory (typically
"eclipse") which is the parent of the eclipse.exe being run or the
plugins directory containing the org.eclipse.equinox.launcher bundle.
This location should be considered read-only to normal users as an
install may be shared by many users. It is possible to set the install
location and decouple eclipse.exe from the rest of Eclipse.
Configuration (-configuration) {osgi.configuration.area} [#none,
#noDefault, #user.home, #user.dir, filepath, url]
Configuration
locations contain files which identify and manage the (sub)set of an
install to run. As such, there may be many configurations per install.
Installs may come with a default configuration area but typical
startup scenarios involve the runtime attempting to find a more
writable configuration location.
Instance (-data) {osgi.instance.area}
[#none, #noDefault, #user.home, #user.dir, filepath, url]
Instance
locations contain user-defined data artifacts. For example, the
Resources plug-in uses the instance area as the workspace location and
thus the default home for projects. Other plugins are free to write
whatever files they like in this location.
While users can set any of
these locations, Eclipse will compute reasonable defaults if values
are not given. The most common usecase for setting location is the
instance area or, in the IDE context, the workspace. To run the
default Eclipse configuration on a specific data set you can specify:
eclipse -data c:\mydata
You must put property definitions like this at the end of the eclipse.ini after the -vmargs line. If there is no -vmargs line you must add one.
So:
.... other lines ....
-vmargs
... other arguments
-Dosgi.configuration.area=/directory/directory1/eclipse.eclipse
Let there be:
There are different repositories repoA, repoB and repoC each respecting the same directory layout principles, which are to be merged onto a third repoM's working directory (the "master" project).
repoM has an atypical setup (--work-dir and --git-dir are sepparate). repo[A-C] are cloned as bare, and they are set as core.bare = false and core.worktree=<--work-dir-of-repoM>.
The requirements:
I need to always have an overview over the history of all files in repoM's work-dir, which could have stemmed from repo[A-C]. With this approach, I lose all that information.
Alternative:
I've been thinking about using git-subtree instead (git version 1.7.11.2, so it's already built-in), leaving repo[A-C] bare, and then
git pull -s subtree, or
git subtree ...
With the subtree pull strategy, I lose the history on a merge conflict (git blame says so).
I've never used subtree before, but from my understanding it's not possible to merge files from repo[A-C] into repoM's work-dir, those files must be put into a subdirectory of repo[A-C]. This is definitely not what I need. Why? Because of the following ...
Problem statement:
You have different git repositories each containing different sets of files, usually configuration files and some shell scripts. You want to put everything in the $HOME (which is <--work-dir-of-repoM>) directory from all those repositories. You should be able to see at all time where each file comes from, edit, commit and push changes to each one's origin. You've guessed it, it something like vundle, but generalized for any kind of configuration of any program, not just vim bundles. If a conflict occures, one should be able to track down which two authors of the same file need to get in touch with each other and make up a deal (if one needs to be made).
This is for an open-source project I'm trying to get a prototype working, so any help is highly appreciated. Also ideas about already existing projects which do this in a similar manner are highly appreciated.
Note: the "master directory" does not necessarily have to be $HOME, I've used it as a possible hint on the kind of problem this could solve.
Why not simply use Git Submodules in your "master project"?