I really liked the feature GitHub Template Repository where according to the documentation
After you make your repository a template, anyone with access to the repository can generate a new repository with the same directory structure and files.
What I also want to accomplish is to copy the the labels and settings of the template repository. This would ease processes and bring in standardisation.
Following could be the possible settings which I would like to be inherited from template repository
Disable Allow merge commits
Rule of master branch i.e. Protected branches
GitHub pages source should be master branch /docs folder
Activate After pull requests are merged, you can have head branches deleted automatically
Have you tried this ? If yes, how were you able to do it ?
2020: For now, "Creating a repository from a template" does not extends to settings, only repository structure.
If said repository is part of an organization, you have a common set of settings you (as administrator of that organization) can manage.
Note: Jorge Leitao adds in the comments:
As of today (Jan. 2023) org-level settings do not support branch rules nor most of project settings (even Enterprise Plan)
Related
I'd like to ask, how may I do a migration of mappings, worklets and workflows from Informatica PowerCenter Integ, to Prod.
Integ Enviroment and Prod are in different servers, so I can't just mouve folder from folder.
Is it possible? I can't find any refernece or tutorial.
Thank you in advance.
In Powercenter, its possible to copy form one env to another. Request everyone to check in their objects first adn log off from both source and target repo.
Open Repository Manager, connect to the source repository and select the folder you want to copy.
Click Edit > Copy.
Connect to the target repository. Connect to the target repository with the same user account used to connect to the source repository. If you do not have same user you need to use deployment group/deployment folder.
In the Navigator, select the target repository, and click Edit > Paste. You will get many options like - replacing objects, use latest version, check out etc. You can follow below link to get help.
https://docs.informatica.com/data-integration/powercenter/10-5/repository-guide/copying-folders-and-deployment-groups/copying-or-replacing-a-folder/steps-to-copy-or-replace-a-folder.html
Now, my preference would be to use deployment group or deployment folder. Its easy to use and easy to control - like if you want to replace 10 objects out of 100s, or you want to create a standard process for future migrations, or deploy using command task automatically, you can do as well.
I have a single Cloud Source Repository with multiple projects. I am able to create a cloudbuild.yaml file in the repo root that builds all projects. However, I don't want to have a build trigger that rebuilds all of the projects since most commits will be for a single project. Ideally I would like to have a cloudbuild.yaml file in each project subdirectory and a build trigger that detects changes in the project subdirectory of the repository. Is something like this possible?
As a possible workaround, I believe I may be able to keep my cloudbuild.yaml in the repository root and create a custom step that will get the commit sha (via the COMMIT_SHA substitution) and then get the list of files committed (via "git show --name-only --pretty=format: $COMMIT_SHA") to determine which project should be built and what image should be created. An alternative may be to have a tagging naming convention that will contain the project name and basing the trigger on that but I don't want to tag each commit.
Note, it seems like build triggers work very well when you have multiple repos but we made the decision to go with a mono repo and I don't want to rehash that debate in this question. I'd like to understand how to best use the Build Triggers in a mono repo.
I see this at codeclimate.com and I want it to go away. What should I do?
I enabled the Code Climate platform and here is where I created my .codeclimate.yml, using the default .yml file Code Climate provides.
Code Climate docs say...
Add a brand new .codeclimate.yml to the root of your default branch
(replace any existing Code Climate config file).
I am probably misunderstanding what Code Climate means by "root of your default branch."
Default branch is defined as: Since Git repositories can contain multiple branches, Code Climate needs to know which the branch to
focus on. We refer to this branch as the default." How do I set my
default branch? "When adding a private GitHub repository (without
entering a URI), or when adding an open source GitHub repository, your
default Code Climate branch will always be set to your default Github
branch...For all other situations, you'll be prompted to set the
default branch...Note: It is currently not possible to change your
default branch after adding a repository to Code Climate. In addition,
once a repository has been added to Code Climate, changing the default
branch in GitHub will not change the default branch in Code Climate.
Code Climate submitted a pull request with the following changes and the warning message went away upon merging.
(fwiw, excellent and prompt customer service)
I have a master remote repository, and two local repositories.
However, it appears that changes to header/footer/css do not propagate throughout the repos.
How can I achieve this?
Fossil will treat the configuration of each of your repository interfaces (whatever you put in the header/footer/css etc) as something unrelated to the versioning of your files. This makes sense when you are working with repositories that you you are not the admin of. You will always be in control of the UI on your local machine (where you are by default the admin) and make it look and behave whichever way you want, even if you do not have priviliges to make the same changes to the central repo.
To propagate changes to the configuration (including the header/footer/css etc) you can use the fossil configuration options. Just type fossil configuration --help to see how you can export, import and synchronize your configuration accross repositories.
After my first question, id like to have a confirmation about the best git workflow in my case.
I have a single django project, hosted at github, and differents clones with each his own branch : customerA, customerB, demo... (think websites)
Branches share the same core but have differents data and settings (these are in gitignore)
When i work on CustomerA branch, how should i replicate some bug corrections to the other deployments ?
When i create a new general feature, i create a special branch, then merge it into my master. Then, to deploy on the 'clients', i merge the master branch into the customer branch. Is it the right way ? or should i rebase ?
# from customerA branch
git fetch origin master
git merge origin master
Also, i have created a remote branch for each customer so i can backup the customers branches to github.
It looks a very classic problem but i guess i dont use git the right way
Thanks.
Ju.
I would have a single project repo at a well-known place containing a master branch with the common code, and branches for specific deployments (e.g. customer/A customer/B demo).
Then I would have checkouts from each of these branches for each customer, for the demo server, and so on. You can let these pull automatically from their respective branch with a commit hook on the single project repo.
Every developer would have their local copy of the project repo, do local work, and then push stuff back to the single project repo.
The challenge will be to maintain the branches diverging from master and doing the regular merges so the diversion do not grow over time.
I have seen this solution describe somewhere in much more detail somewhere on the web, but I could not find it quickly again. Some blog post on using git for a staging and production web server, IIRC.
If the three sites share some 'core' code (such as a Django app) you should factor that core out into its own repo and use git submodules to include it in the other projects, rather than duplicating it.
I would have a repo called project-master or something like that and a repo for each client. Then, when you have code you need to be available to those client repos, you pull from the project-master to that repo.
Don't separate the projects in branches, separate them into different repositories.
Make the "common" code generic enough so that costumerA's copy of the common code is exactly the same as costumerB's copy of the common code.
Then, you don't have to pull or merge anything. When you update the common code, both costumerA and costumerB will get the update automagically (because they use the same common code).
By "common" code: I'm referring to the package/series-of-apps that power the websites you're developing.
I'm assuming costumerA and costumerB repositories would only include things like site-specific settings and templates.
The key here is making the "common" code generic: don't let costumerA use a "slightly modified version" of the "common" code.
Also, I'd suggest using a deployment mechanism that doesn't rely on git. git is a great source code management tool; but it's not designed (AFAIK) to be a deployment tool.