Hot answers tagged

22

Let's take it word by word: Self: You or your organisation owns this thing. By contrast, a cloud-based offering by GitHub.com, Azure, GitLab.com, etc. (see this list on Wikipedia for a more comprehensive list) is not owned by you, but rather the service provider in question. Do not confuse ownership of the code (dictated by it's license – typically owned by ...


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 ...


10

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

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 it's clunky. Also they don't offer a fine grained view of changes, as one version change might involve a large amount of changes. When ...


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

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.


6

I guess the simplest and direct solution would be to use GitHub API: https://docs.github.com/en/rest/reference/pulls#create-a-review-for-a-pull-request But for the requirement you have, PR checks is usually the way to go and you have a plugin that does the API communication for you: https://www.jenkins.io/doc/pipeline/steps/pipeline-githubnotify-step/


5

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, ...


5

Assume you have your own IT infrastructure, eg a Linux server or a good old mainframe, on which you are running (hosting) your VCS software of choice, e.g GIT or ChangeMan ZMF. In such case you have a self hosted hosted VCS. As compared to GitHub, which is a web-based hosting service for software development projects using Git.


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

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 ...


4

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 { ...


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 ...


4

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


4

An example will be maybe worth a thousand words: $ sudo apt install git $ ssh 192.168.0.110 kub@host:~$ git init --bare repo1 Initialized empty Git repository in /home/kub/repo1/ kub@host:~$ logout Connection to 192.168.0.110 closed. Voila, We already posses a self-hosted version control system. Let's use it as an example client: $ git clone 192.168.0....


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 ...


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

You do not need to include anything into your assembly to run your tests using GitHub Actions. Just create workflow file in .github/workflows folder with the following content (assuming that you have .NET Core project): --- name: Tests on: push jobs: tests: name: Unit Testing runs-on: windows-latest steps: - uses: actions/checkout@v2.1....


3

There's a simple two step process... In your originating job, tick step [ X ] Archive the artifacts and set the files to archive. The files are copied to the master, stored in the jobs folder tree, under the builds directory for each build, along with the log. (Delete the build and it deletes the artifacts that came from it). Install the Copy Artifact ...


2

I recently ran into the same error. In my case, I had rebased a branch and was attempting to push to the remote. One of the pulled commits had changed the structure of a few directories, and git refused to push after the rebase, throwing: fatal: ambiguous argument 'path/to/scripts': unknown revision or path not in the working tree. Use '--' to separate ...


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

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 ...


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

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 ...


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

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 ...


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