Hot answers tagged

11

Microsoft has heavily invested in their Git Virtual File System. It is unlikely then that such a key system central to Microsoft's internal development processes will be going anywhere any time soon, and GitHub is a smart dovetail with Microsoft's portfolio and strategic direction. Microsoft has recently been moving towards more freemium services - which ...


8

The easiest method is to have Eclipse generate an Ant build script for you. Right click on your project in the Package Explorer and select Export in the context menu. Choose the export type General -> Ant Buildfiles and click Next. On the next screen, make sure your project is selected. You can keep leave the options on their default settings. Click Finish ...


8

This is a simple thumb rule one could follow Use version control (git, svn, cvs) for the work product created by humans Use artifact management tool (artifactory, nexus, apache archiva) for the software bundle (artifacts) created by the system thru build or packaging process HUMAN ==> System GIT/SVN (build/packaging) ...


7

You have to pass only the repository not the full HTTP URL of the repository when you want to delete it from what I've read in the documentation. So the command should be: ansible-galaxy delete 030 ansible-firewall


6

Version Control (using say git) and Artifact Management (using Artifactory) are complementary. Version control is useful for easily browsing the historical changes and who made them. Artifact management tools can do this but its clunky. Also they dont offer a fine grained view of changes, as one version change might involve a large amount of changes. When ...


5

Instead of using Travis' deployment features, build the deployment logic in to your normal "test" script(s). For a PaaS this might be as simple as pushing to another git remote if all tests pass, but the sky is the limit.


4

The error looks like you're using a non-existent reference (branch/tag). Try specifying the correct branch and tag using the branch/tag options. You can also use the commit hash directly using ref option. Also ensure that your git URL is correct (your code does not contain the xxx.git part).


4

Travis CI supports deployment on branch release by using the following syntax: deploy: on: branch: release The problem is that GitHub does not support it. As per GitHub Releases Uploading page at Travis CI: Please note that deploying GitHub Releases works only for tags, not for branches. For GitHub the only workaround is to push tags (e.g. git ...


4

The guidance that we've always followed in my various scrum teams is developers should get what they've got into testing as soon as possible. It may mean a little rework later on down the line if there are issues found in code reviews or developers haven't completely finished coding, but the earlier developers get feedback on what's been done, the earlier ...


3

This sounds like a problem for git cherry-pick. If you can separate the user story code from the fix code, by committing them separately, you can cherry pick the relevant commit to merge back into the develop branch. See https://stackoverflow.com/questions/9339429/what-does-cherry-picking-a-commit-with-git-mean


3

Short answer Ideally, you should store secrets as environment variables, and retrieve them from a secrets management system like Hashicorp's Vault or AWS Parameter store. Long answer I saw your questions out of turn, and kinda touched on this in your other question: Again, there are many perfectly valid options for handling secrets: Chef vault, ...


3

One could use conditional builds https://docs.travis-ci.com/user/conditional-builds-stages-jobs/ If code is merged into master one could decide to deploy code to production, but I personally prefer a human intervention by a Product Owner. jobs: include: if: branch = master or stages: - name: deploy # require the branch name to be master ...


3

There is no "right" or "wrong". If the commands work when you type them in, then they work, and we won't keep you from doing it. Everything else is opinion. Sure, there are some best practices, for example some people find it unwise to directly fetch scripts from a public (3rd party) website and execute those locally without having a look inside first. It ...


3

Open the PR, even if it's not ready. Basically, allow the QA testing & code reviews to operate in parallel. Pros: code review and testing can operate in parallel. Cons: if issues are found in testing, the code needs to change, even though it has already been reviewed. When code review prompts changes, testing has to be redone. This encourages the ...


2

You may wish to try scripting the actions you want. Then use git hooks to trigger your scripts to release the latest code to your environment. Alternatively, you could use something like Jenkins to configure a "push on green" system if you are working with compiled code. Lastly, (though I haven't used them) Amazon claims that their CodePipeline product can ...


2

one strategy is to put your playbook repo(s) thru a regular build/deploy pipeline, where you separate between "nonrelease" and "release", for example by linking the master branch to "release" (most CI tools support this out of the box). Then you'd have two "streams" of artifacts you could deploy, one for release and one for non-release (or release candidate ...


2

I am assuming you are using Jenkinsfile. You can do for example: pipeline { agent any stages { stage('Build') { steps { echo 'Building..' } } stage('Test') { steps { echo 'Testing..' } } stage('Deploy') { when { ...


2

Your idea will work. The organization I work for maintains some open source examples how to do deploy to AWS using a pipeline. In comparison we use GitLab for the purpose. Instead of Travis we use GitLab Runner. You configure it using the file .gitlab-ci.yml which runs the tests and deploy the AWS Lambda to dev, test and production environment every time a ...


2

You can do via docker, since it's a test. Here is an example repository, both docker and vagrant. https://github.com/jonashackt/gitlab-ci-stack https://blog.codecentric.de/en/2018/05/gitlab-ci-pipeline/


2

It’s not clear exactly what level of trust you have towards contributors. You could update your question to explain a bit more about whether people are all on one team or might be strangers. One feature that is likely to help is “branch protection settings” on this protected branches article. You can state that only code reviewed PRs are allowed into a ...


2

This question ties in heavily with your other question with where the secrets are set and where they retrieved from. I assume your question is asking about 'canary deployments' where you change the config for only a small portion of your apps, to test things out before deploying everywhere. If you follow the best practice of using the 12 Factor app's ...


2

Here is a Webhook rule to catch Github release events and run a custom bash script. It is run by adnanh/webhook which is a small go app that can run your deployment script. You then configure GitHub to send release events as per this screenshot: You can then use the github hub command line tool to create releases with a name that matches the regex in the ...


1

From my understanding of the docs, you should directly send an array (which is valid JSON), without wrapping it in an object. That is ["bug"] instead of {"labels": ["bug"]}. So, the proper request should be: curl -X POST -u githuser:gittoken \ https://api.github.mycompany.com/repos/team/repo/issues/560/labels \ -H "Content-type: application/json" -...


1

If you are using Gitlab merely as a source code repository, and you are triggering the jobs when there are changes to the repository. The Jenkins Gitlab plugin documentations states: This plugin is a build trigger that allows GitLab to trigger Jenkins builds when code is pushed or a merge request is created. Configuration done on a per-job basis. So, ...


1

It is a convenience that Jenkins will pull from git for you. With such a complex setup as needing to pull from two repos you can simply use a pipeline job that runs "sh" to explicitly git checkout the code and pull the submodules: sh "git checkout ${custom_env_var} ${custom_parameter} The good news with this slightly manual approach is that you can debug ...


1

Usually you want to test your code as closely as possible to how it's going to be deployed. This means you're going to want to run your tests against code that's been merged with master, so choose the first option (merge first, then test). There's no point in the 2nd option if you're never going to deploy the code in that state (i.e. unmerged). Or for ...


1

First, you have to create a new job in Jenkins ( Github organization ) and configure it to scan all repos and all branches, you can do it by following this URL second, press scan organization from Jenkins, now you will see all repos and all braches which contain Jenkinsfile which contains all your stages and all pipeline stages, check also this URL


1

According to the official GitHub Branch Source Plugin documentation, the plugin can automatically configure webhooks for you if you have your GitHub API token configured in Jenkins global settings: You can change the build configuration to perform the folder computation at different times. The default setting will scan your GitHub repository for ...


1

Finally I have resolved it with the help of "strategy of choosing what to build" with "Default behavior" for each branch.


1

The updated deploy script in the question supports the following workflow (and requires this server setup): Create a feature branch and push commits to it Each push deploys the code to the staging server Review the code with merge request (feature branch --> master) After merging to master, create a new merge request (master --> production) Due to Github ...


Only top voted, non community-wiki answers of a minimum length are eligible