adding gitpod configuration #52
Conversation
Codecov Report
❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more. @@ Coverage Diff @@
## gcos4gnucobol-3.x #52 +/- ##
=====================================================
- Coverage 65.29% 65.17% -0.12%
=====================================================
Files 31 31
Lines 56789 58384 +1595
Branches 14851 15380 +529
=====================================================
+ Hits 37078 38051 +973
- Misses 13885 14402 +517
- Partials 5826 5931 +105
... and 1 file with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
GitMensch
force-pushed
the
patch-2
branch
2 times, most recently
from
d2653ed to
180b3d9
Compare
|
@lefessan @nberth What do you think of this? A testing should be possible from this URL: https://gitpod.io/#https://github.com/GitMensch/gnucobol-1 (hm, and authorize gitpod, I see that this can be an issue, but maybe you still try that) |
|
rebased and rechecked, seems fine to me (one could use the vnc base workspace definition to allow running the manual screen tests; but that can be done, later, too |
|
Juist found out that I've set that to draft months ago... @ddeclerck do you have suggestions compared to the common CI?Would it be reasonable to use the docker you seem to build on/for gitlab? Does it have all the tools installed and is public accessible? |
I'm clueless about GitPod...
Which docker image are you referring to ? |
With gitpod you don't have any artifact as it opens an online vscode instance connected to a running docker - you have all the files ready at hand with the current revision used. Still - if you have any suggestions then feel free to drop them :-)
I've stumbled yesterday over Line 3 in 21b5d51 Maybe that's something reasonable to use in general, and comes with all the dependencies included? ... self answer when checking further down: the dependencies are installed as pre-script, so reworded question: "Shouldn't those be part of a new image that possibly is based on the other one and includes all dependencies - along with those in the gitpod file here and the ones used in the github ci?" |
Looks interesting ; I shall give it a try if I find a moment.
I wasn't even aware of that GitLab CI 😅. Apparently that was added during early experiments on our internal GitLab instance, before we created the GitHub mirror. The docker image you mention has been made by another team at OCamlPro (I believe it is automatically generated and refreshed from time to time) and is intended for OCaml development. I'd have to check with that team if we can come up with something to use for GnuCOBOL on GitPod. |
If I'm not wrong then we could also use this in the github CI (with the goal of decreasing CI minutes, which is also beneficial to the environment). |
|
@ddeclerck @lefessan This PR should work as-is already and improve the use of the repo on GitPod. Can you please pull that into the gcos3 and gcos4 branches? We can come back to adjust this later to care for a possible new base image. |
|
Hi @GitMensch , |
this file alone only "prepares" for use of GitPod, but I consider this useful, too
I suggest to additional do the following, after #51:
but as noted, that's "optional"; some benefits of GitPod: nice performance, running without costs, full coding and building possible in the browser from anywhere, when pre-builds are active the development can start nearly in an instant, in theory also easy for people to start coding on the project