Port CI to GitHub Actions #32
Conversation
This should emulate the behavior of the previous Azure Pipeline CI build. The only exception is the build artifact is
now stored as a GitHub Actions workflow artifact rather than on Azure Pipeline.
To work around the actions/upload-artifact action's behavior of removing executable file permissions from the workflow
artifacts, I uploaded the archive file as the artifact. The downside to this workaround is you get a .zip file inside of
a .zip file:
binary_Linux.zip
|_ arduino-language-server_Linux_amd64.zip
|_ arduino-language-server
|
@rsora this will require the creation of the |
That's not a problem for the Pro IDE. It uses the s3 download link. |
|
|
||
| - name: Publish Nightly [S3] | ||
| if: github.event_name == 'schedule` || github.event_name == 'workflow_dispatch' | ||
| uses: kittaakos/upload-s3-action@v0.0.1 |
There was a problem hiding this comment.
Maybe It's time to check if the guy merged the fix proposed by Akos in the upstream repo?
There was a problem hiding this comment.
It's still open: shallwefootball/upload-s3-action#10
It looks like the PR has some requested changes.
I see there has been a release in the upstream repo since the point we're using in the fork. If I understand correctly, the benefit of using the kittaakos/upload-s3-action action instead of upstream is correct error handling, so, if everything is working correctly, it should be possible to use the upstream instead if you prefer. On the other hand, we won't know whether it's working correctly until after this PR is merged, since this publish step is the only part I didn't test.
There was a problem hiding this comment.
It's still open: shallwefootball/upload-s3-action#10
It looks like the PR has some requested changes.
I will do an update.
On the other hand, we won't know whether it's working correctly until after this PR is merged, since this publish step is the only part I didn't test.
+1 for sticking to the forked action in the PR.
Done! |
My understanding is that the sole purpose for the step publishing the pipeline artifact in this repository's current Azure Pipeline configuration is facilitating beta testing. Is that correct @kittaakos ? |
There was a problem hiding this comment.
is facilitating beta testing.
FYI: It's always easier to build the LS locally and try it out immediately with the Pro IDE.
For me, the workflow should be something like this:
- build on all platforms then use
actions/upload, - use
actions/downloadon Linux only, - and do the s3 upload only when all platform builds were green.
I agree with @per1234's sugggestion:
I'd say that particular improvement would be better as a separate PR to keep this PR about a straight across port.
Let's keep everything as-is for now.
I am going to try the LS in action today. Please keep this PR open until we have the 0.0.7 Pro IDE release.
|
|
||
| - name: Publish Nightly [S3] | ||
| if: github.event_name == 'schedule` || github.event_name == 'workflow_dispatch' | ||
| uses: kittaakos/upload-s3-action@v0.0.1 |
There was a problem hiding this comment.
It's still open: shallwefootball/upload-s3-action#10
It looks like the PR has some requested changes.
I will do an update.
On the other hand, we won't know whether it's working correctly until after this PR is merged, since this publish step is the only part I didn't test.
+1 for sticking to the forked action in the PR.
|
I am going to merge this change. If something does not we can still do a revert. Thank you, @per1234 👍 |
This should emulate the behavior of the previous Azure Pipeline CI build. The only exception is the build artifact is
now stored as a GitHub Actions workflow artifact rather than on Azure Pipeline.
To work around the
actions/upload-artifactaction's behavior of removing executable file permissions from the workflowartifacts (actions/upload-artifact#38), I uploaded the archive file as the artifact. The downside to this workaround is you get a .zip file inside of
a .zip file: