I'm trying to record information about a repository using JGit. Is there a way I can find a submodule's URL and other info from a specific commit in the parent repository?
I've tried to walk through the repo using a SubmoduleWalk, but since the final version of the Repository may not contain the submodule (if it was deleted later), it doesn't seem to find the submodule.
Related
Is there a way to alter a build using the CLI after having published it?
UseCase: A deployer (be it automated or manual) wants to add additional files (e.g. Testresult-logs) to an already published build (because they need very long to be created but the artifacts of the fresh build should be published asap).
When I redo a jfrog rt bp over and over again I get "new" builds with the same description (same buildnumer etc.) instead of overwriting/extending existing build.
Appreciating any hint :-)
The main idea of the buildinfo in Artifactory is that they are immutable, which means they cannot be modified post publish. This is to make sure the integrity of them.
In your case, a possible way to achieve this may be:
When publishing the artifacts themselves, you might want to not publish the buildinfo.
You can collect buildinfo through your build cycle, and publish everything as a single buildinfo object after all the tests.
If you want to use a package between two projects, what's the best way to handle it. Considering two scenarios :-
First Scenario
Git Repository with the two projects like
root folder
-- Mobile App Folder
-- Web Folder
So both projets are in the same repository
Second Scenario
Each project is in separate Git repositories and we want to share the package between those projects.
What's a good ways to handle each scenario? ( Either using the same method for both, or different methods for each scenario)
You need to be aware of how Meteor handles package scanning when confronted with meteor add package :
searching for it inside the local packages/ folder of your app.
searching for it inside every folder specified in the PACKAGE_DIRS environment variable.
searching for it on Atmosphere.
Not sure about the specific order but I'm assuming the one that makes most sense.
So your question is basically where to store the package for an optimal workflow.
Using the fist scenario, you would store your private packages inside the app root folder under packages/, you'll just have to git pull from the repo to get the latest versions of the packages. Then you would have to make sure to define correctly the PACKAGE_DIRS env variable, something like this :
export PACKAGE_DIRS=$PACKAGE_DIRS:$HOME/meteor/my-repo/packages
Using the second scenario, you would store each private package on its own git repo, then pull them into a local $HOME/meteor/packages of yours and don't forget to set PACKAGE_DIRS appropriately.
export PACKAGE_DIRS=$PACKAGE_DIRS:$HOME/meteor/packages
I would tend to go with the second scenario if there's a chance that these private packages may be reused for other projects, if you are sure they only make sense in a particular project, then storing them along in the repo is OK.
Another option would be to symlink your shared private packages into the "packages" folder of each of your apps.
So assume you have have your shared package in the folder /dev/mysharedpackage. You could create a symlink via ln -s /dev/mysharedpackage packages/mysharedpackage and then add the package via meteor add.
Here is a Meteor Cast on this topic: https://www.meteorcasts.net/ep/3
My team has is working on a git repository which contains a fully deployable Wordpress app. This was configured in this way so that it could be deployed to a AWS stack quite easily. The repository contains a caching plugin which creates two folders in the wp-content/ folder named
cache/
w3tc-config/
When devs are checking out this application they are removing the caching features for development and thus the plugin is writing these changes to the two directories it uses. Which then encourages .git to stage them for a commit.
Is there anyway we can ignore these folders on dev machines but not remove them from the repo? Also i'd be interested in hearing other solutions which might help me get round this problem even if it is a larger change.
If you check out your repository and let master follow that, then you can create a devel branch where you just add cache w3tc-config to .gitignore.
I do something similar at work where I use git-svn to work with a svn repository which "links" in another svn repository for a sub module. Git clone did not fetch that sub module, so I just copied in the content from a svn checkout, checked into a devel branch (leaving master following the svn trunk branch), and added the sub module directory to .gitignore.
This is a solution that will require specific action from each developer, and not something you can push out from the repository. But similar to git hooks, if you create a tools/do_it.sh script that does the required actions it is possible to lower the bar considerably.
You cannot have it both ways. Either the files are tracked or they are not. You cannot keep files in the repository but avoid tracking changes to them. Once they are tracked, it is up to you to not git add them. (And it is worth noting that git does not track folders ever.)
Create an archive called UnzipMeRightAfterCloning.zip that contains all the stuff you want ignored. Anyone cloning the repo needs to extract that archive, and it will add all the files/folders blocked by your .gitignore settings. (And given your current setup, you will have to untrack the files in those folders first.)
Put these in your .gitignore file. (Do not put in asterisk.)
cache/
w3tc-config/
Yes, create a local .gitignore file in the project directory.
in the file paste the following
cache/*
w3tc-config/*
Now, these files will be excluded from git, but they won't be removed from the repository.
I want to commit to a Plone package. Do I include it with mr.developer? If yes, the code is in buildout-folder/src. After I made my changes, how do I commit with my existing github account? Should I use something different than mr.developer?
If you have a fork of the package in your github account, then using mr.developer is an excellent way to make local changes.
Just use normal git tools. The repository is indeed located in the src/ directory, just cd to it and use a normal git workflow. Then use GitHub to issue a pull request to the original package for your changes.
All mr.developer does is make it easier to switch buildout to use the development egg stored in src/ and to make the workflow of working with 1 or more repositories for eggs-under-development. It doesn't require you to do anything special with a version-control managed package.
I have a private bundle that I import in the vendor.
Now, I'm working in my project and want to edit some code in the vendor bundle.
Now I've done that and want to commit to code, so I go the dir of that bundle and say: "git commit -a" so I give a message, save and now I have a commit. Oke, "git push" and give the response "Everything is up-to-date"... So I can't push that but I can commit??
Is this not a way to commit? Should I just clone the repo and work there?
You should never edit the vendor code directly - this is the whole point of dependency management.
Composer basically works by looking at your composer.json file, and fetching the repositories and versions you specify. If you need to make changes to one of your dependencies, you should make the change in the original repository, push the changes up to GitHub (or wherever you're hosting the code) and run composer update.
When Composer installs a vendor, it checks out a particular commit, so you are not on a branch. You need to checkout the master branch — or whichever you're using — and commit to it and push it.
Its a long time ago that I asked this question. Mean while I got the answer but never updated my stackoverflow question, sorry for that!
The answer on my own question is to get the dependency with composer --prefer-source.
https://getcomposer.org/doc/03-cli.md#install
--prefer-source: There are two ways of downloading a package: source and dist. For stable versions composer will use the dist by default. The source is a version control repository. If --prefer-source is enabled, composer will install from source if there is one. This is useful if you want to make a bugfix to a project and get a local git clone of the dependency directly.