Our team develops an application. As this application intended to run on Debian, we’ve done it in a proper Debian way – via .deb packages. This app is written in C++/Python and versioned using Git.
We have a private Debian repo where I place snapshot and release versions (approach taken from Java world):
- appname-1.2-SNAPSHOT.deb
- appname-1.2.1.deb
Now some of developers have branched, have writen code and finally are creating pull requests. By pull request I want to trigger the testing of his work – make sure it is not so bad to go to master branch.
So I am creating the VM and.. what should I install from Debian repo before triggering the test? What is the best practice?
When testing a pull request, you want to verify that the result of accepting/merging the pull request into the current master branch does not immediately break all kinds of things.
This means that the version being tested on the VM must be the result of merging the pull request into master.
If your question is about what to call the Debian package that contains this software “version”, then there is no standard for that. This depends too much on how the infrastructure around your project is organized.
If there can be only one pull request that is being tested before merging, then you could just use a fixed name, like appname-PRE_MERGE.deb or appname-PULL_REQUEST.deb.
If there can be multiple active pull requests, then it would be better to encode the name of the source branch in the package name, so that the different pull requests don’t interfere with each other.
In any case, these pull-request packages should be deleted from the repo when they have been tested (and passed), as they don’t have any lasting value.