search

PhilterPaper / Perl-PDF-Builder

Extended version of the popular PDF::API2 Perl-based PDF library for creating, reading, and modifying PDF documents
https://www.catskilltech.com/FreeSW/product/PDF%2DBuilder/title/PDF%3A%3ABuilder/freeSW_full
Other
6 stars 7 forks source link

+ ci for github #131

Closed carygravel closed 3 years ago

carygravel commented 3 years ago

This way, every commit that is pushed triggers the tests to be run and a linter to look at the code. You'll then get notifications about any failures.

carygravel commented 3 years ago

Note that we can set up runners for 6 different versions of windows, linux & macos with different combinations of dependencies present.

PhilterPaper commented 3 years ago

Interesting. Do I just create a workflows/ in the local .git/ directory and put the file there? Where does it run -- on GitHub? Do I need to do anything else on GitHub to enable it? Does it refuse to accept a push to GitHub if it finds a problem, or does it just tell me in some way (preferably by email)?

PDF::Builder inherited Travis usage (CI) from PDF::API2, but I recall having lots of problems, and PDF::API2 reports that it may no longer be working with recent Perl releases. I disabled it some time ago (see /INFO/old/.travis.yml.HOLD). Is this a replacement for Travis?

carygravel commented 3 years ago

This is all specific to github, and therefore sits under .github/workflows/, not .git. It runs on Github. I expect you can set it up to refuse the commit if you want (which would slow everything down by the 5mins needed to run everything). The pull commit just sends emails and puts the results in the "Actions" tab.

All CI systems are inherently similar, but I'm not aware of a closer connection between Travis and Github's CI.

carygravel commented 3 years ago

Look here for example output.

PhilterPaper commented 3 years ago

OK, so do I end up creating a local .github/workflows/, and whatever .yml files I put in it end up being treated like anything else? Will any changes to test.yml be flagged as needing to be pushed to GitHub? Or does it work differently? My current workflow is when ready to update GitHub, I git add <files>, git commit -m"description", and finally, git push. Does this change? If I understand you correctly, I'll get notifications at least by "Actions" tab, and presumably email. I see in your "actions" tab, the error message from the first push doesn't look very informative (it didn't like "name: Test"?). Was this a problem in Test.yml itself (resulting in your update)? Finally, the example GitHub Actions uses Main.yml, and you use test.yml. Is the name arbitrary? Do all *.yml get run? In what order?

carygravel commented 3 years ago

Any changes to the .yml files must be pushed in order for them to be acted upon. They are part of the repo, just like any other file.

Your workflow stays the same.

The error message seems reasonably helpful in the first commit. The problem was that I asked it to install Graphics::TIFF in ubuntu-latest, but I've only just uploaded it in Debian. It won't be in Ubuntu until the next release. But that's fine - we can leave it out until then, which is the change I made in the second commit.

Without looking at the documentation, I'm guessing that the name is arbitrary, and that the order is undefined, but irrelevant.

PhilterPaper commented 3 years ago

OK, let's see how this works.