Should we also do CI builds of Dosbox-SVN? as a test/compare base

[LowLevelMahn]

is there any interest in building Dosbox-SVN (branch) on the CI? so that there is always a vanilla dosbox version for comparison available?

im building Dosbox-SVN locally with VS2019 (and self build dependent libs (SDL,pdcurses,...) and could maybe switch that to use vcpkg

Code of Conduct & Contributing Guidelines

• Yes, I agree.

[arrowgent]

i use this for frequent svn builds

https://code.launchpad.net/~i30817/+archive/ubuntu/dosbox-patched

though i normally have it disabled because it would update nearly everyday and i dont use it that often...

[LowLevelMahn]

i would prefer a CI build of dosbox-staging SVN-Branch - build on the very same CI as the staging releases
just to be safe that everything is vanilla as possible

im building Dosbox-SVN under Linux/Windows always by myself - but a CI build could be a better reference for other testers that are not able to build it

[kcgen]

I can see the benefits from a testing perspective and to help those authoring patches in general (to SVN and multiple forks).

I would certainly be open to an SVN builds workflow, provided it:

• Triggers on pushes to the svn/trunk branch
• Informs users that its intent is for development / testing / QA purposes for the Staging project only
• Points readers to the upstream DOSBox project website and vogons, for supported DOSBox releases and sources
• Warns users not to report issues against this specific build: instead, they need to use a supported build (from whatever project they're using), downloaded from an official site.
• Names the binary itself to indicate it's not supported, perhaps:
  dosbox-svn-r4470_unsupported_for_testing_only.exe
• Explores if technical safeguards could be put into place to limit exposure of the build artifact (if GitHub supports something like this).

I know all of our hearts are in the right place, we're just trying to progress DOSBox in general, but my biggest fear is that this comes back to bite us: users deliberately ignore those messages and run to vogons with false-positive reports, where DOSBox Team members now have to ask: "Ok, you say you're running an SVN build, but first we need to ask where you got it."

Ultimately, we would take down the workflow if this build is misused or a nuisance for the core team.

I should also say that this doesn't have to be something Staging does. There are several github mirrors of SVN out there. A workflow could be added to their CI jobs as easily as it can be added here.

• https://github.com/svn2github/dosbox
• https://github.com/wjp/dosbox
• https://github.com/jwilk-mirrors/dosbox
• https://github.com/shlomif/dosbox

[Grounded0]

As we're getting along well with the DOSBox team we must tread carefully here as stated by @kcgen.

[LowLevelMahn]

@kcgen
fully understandable

sad that even stuff like auto-builts "can" become a problem

"Ok, you say you're running an SVN build, but first we need to ask where you got it."

and it still a difference if i say: "build by myself" or "from the dosbox staging project" :/

[arrowgent]

yes i can see it would be beneficial as some baseline test for staging's changes

ive seen other repos build their plugin library against a main repo and keep a local backup ci
those are more lined up with specific release versions x.x.x-ci, not a constant flood of svn changes or even daily ones.

[LowLevelMahn]

ive seen other repos build their plugin library against a main repo and keep a local backup ci
those are more lined up with specific release versions x.x.x-ci, not a constant flood of svn changes or even daily ones.

i don't understand this sentence fully: what is a plugin library in context of dosbox? what do you mean with build against a main repo?

for dosbox-staging its this:
currently the offical releases under: https://github.com/dosbox-staging/dosbox-staging/releases
recent development builds can be found here: https://dosbox-staging.github.io/downloads/devel

the same could be done for the dosbox-svn source - ignoring kcgens concernes :)
and it would be the same - official release builds + svn-change builds (the flood)

you talking about archiving some versions or only building selected svn-changes - but who should select them/and why?

[kcgen]

Archived discussion to https://github.com/dosbox-staging/archived-discussions-for-dosbox-staging