Hot answers tagged

5

Simply keep pushing stuff between the repositories. Git pushes are designed for exactly that. So, if origin is the old repository, and newis the new one, and you want to move new stuff in the master branch from origin to new, then, locally: git checkout master && git reset --hard # to clean up any local changes, optional git pull origin git ...


4

Visual Studio Team Services has a YAML Build feature in public preview that allows you to store your build definitions as source controlled files.


4

The strict answer is no, in that there is no direct equivalent to a Jenkinsfile. However, there are Build Process Templates and you can use the Psake Build Automation tool in combination with templates to reduce the barriers to entry for creating a new build, test and deployment build definitions. It is nowhere near as fluid as Jenkins' Pipelines as Code, ...


1

The service hook will fire as part of the notifications process. You can suppress all notifications by setting the URI parameter suppressNotifications to true. An example request URI might be: PATCH https://dev.azure.com/fabrikam/_apis/wit/workitems/{id}?suppressNotifications=true&api-version=5.0 See the work item update API documentation for more ...


1

I believe your primary issue is that you have this group of users in the [Team Foundation]\Team Foundation Administrators group or possibly many users added with privileges to the Administration Console Users, which is unusual. To adjust who is part of the Team Foundation Administrators group: RDP to the server that hosts the application tier for your TFS ...


1

This is a general issue with react apps that is independent of what CI/CD stack you use that is discussed at https://stackoverflow.com/questions/49975735/rendering-an-environment-variable-to-the-browser-in-a-react-js-redux-production With the Azure family of CI/CD products it is expected you create a release artefact then release that same artefact into ...


1

Since on-premise TFS and the newly renamed Azure DevOps Server 2019 still have the concept of collections, which is the highest level of separation of data you can have (separate physical databases), you'd need to treat a code repo in Collection 1 as an external repository rather than try to discover it as a known internal repository. You can do this in the ...


1

IMHO from the workflow prospective code coverage measurements are fundamentally similar to builds, smoketests or any other types of QA checks and can thus be performed in similar manner. I can see several options: include them in the PR verification path, just like builds and/or smoketests, similarly positioned relative to the code review stage. include ...


1

The conflict is occurring between ngc and webpack. When rimraf aot && ngc -p ./tsconfig-aot.json is moved to its own script and executed prior to test and build:prod:aot then running test and build:prod:aot with npm-run-all will work as expected. Also, running with PowerShell is not necessarily a good idea since it interprets some of the output ...


1

There are two options when publishing artifacts: Server and File Share. If you publish to the server, they are stored in the TFS database. You can't configure the location, however you can configure retention policies to ensure that old builds aren't kept around forever. If you publish to a file share, they're stored on, well, a file share.


1

In my opinion, there should always one key per user: Security: If an employee will leave the company then the key could be revoked and the person who left the company cannot trigger builds anymore Access-control and responsibilties: developers from team b are allowed to deploy apps to the production environment of team b, while members of team a are ...


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