You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/1159
-- Commit Summary --
* Migrate from Travis CI to Github Actions
-- File Changes --
A .github/workflows/build.yml (176) D .travis.yml (99)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/1159.patch https://github.com/geany/geany-plugins/pull/1159.diff
@eht16 pushed 1 commit.
de5565773e3601e541be066110fbde71bb6e1ca4 trigger build
@eht16 pushed 1 commit.
5bf9f10d26eab78423cfba016ee9ebe967c9c8eb dont use env in env
@eht16 pushed 1 commit.
ca759cf60b00ee75856c1fb23cfc5353dafee887 Try without context
@eht16 pushed 1 commit.
da70c0da07a8cc6e44779037a7b3d5b77d974f65 Use RUNNER_TEMP as TMPDIR
@eht16 pushed 1 commit.
d7363d4b49f711a61b6827bd4d72a9d9b03511e2 Try quoting env vars
@eht16 pushed 1 commit.
f034272bd52422a7dfa62136795ffee559d010a1 Giving up
@eht16 pushed 1 commit.
c7438289c4f81d51ab39417644c9f75de05fe234 Fix CCACHE_DIR
@eht16 pushed 1 commit.
deb884313c932f6f6a6a0c53600b2021ec5fd3e3 Next build to test caches
@eht16 pushed 1 commit.
78303c2eb01ee40b394b71c60151d3f88e332e4a Add PR_NUMBER env variable
Question/challenge, can CI be made to build each plugin individually to avoid the current Geany_lua situation where one plugin failing stops any succeeding?
Interesting idea. In theory, this could be easily possible with a matrix configration (it's like you start many builds with parameters).
Though the matrix approach could be very time consuming as all build steps are replicated for each plugin. I think such situations as with GeanyLua won't happen that often, hopefully.
For now, I will concentrate on a more 1:1 migration which is already pretty good. Then Windows builds will follow with a resulting ready to use installer.
@eht16 pushed 1 commit.
5059edb47cef446052ca6c4a85b4e0605ef3422b Try jwalton/gh-find-current-pr@v1 to get PR number
all build steps are replicated for each plugin
What I was thinking of was to have the CI setup and build Geany done once then
``` ./configure --disable-all-plugins --enable-xxx; make install ``` where xxx cycles through each plugin.
My ulterior motive was then to read something like `[xxx]` from the PR and only do that one :-)
For now, I will concentrate on a more 1:1 migration which is already pretty good.
Sure, as you say its rarely been a problem
My ulterior motive was then to read something like [xxx] from the PR and only do that one :-)
Or maybe CI could ask git which directories (== which plugins) are modified and build those.
Or maybe an AI bot could work it out, I here Sweet Geany is unemployed ;-P
@eht16 pushed 1 commit.
bb34a87779f0ad4a619fe43e49d2931f4b8dd8b7 Cleanup
@eht16 pushed 1 commit.
2e60e2163b71e7d210d7f36616dbd05fbab2c096 Migrate from Travis CI to Github Actions
My ulterior motive was then to read something like [xxx] from the PR and only do that one :-)
Or maybe CI could ask git which directories (== which plugins) are modified and build those.
Or maybe an AI bot could work it out, I hear Sweet Geany is unemployed ;-P
:)
As said, I would leave it for now and get the current full build in first to finally move away from Travis.
Maybe we could move your suggestion to a seperate issue, maybe someone else wants to work on it.
Maybe we could move your suggestion to a seperate issue, maybe someone else wants to work on it.
Done #1163
Great.
@elextr @kugel- any objections? This is the last repository where Travis-CI is used.
No objections, go for it!
Do it, and thanks for the effort.
Merged #1159 into master.
Cool, merged. I'll keep the Travis CI integration enabled for some time, so existing PRs can still be built without having to rebase to master. At least as long as the remaining credits will not run out again.
github-comments@lists.geany.org