Add GitHub action/workflow for build and deploy

[fscheiner]

No description provided.

[fscheiner]

This should now also enable the building and deployment performed with GitHub Actions but isn't tested yet. I'll merge it into my local master branch to make the GitHub Action work in my fork for a test of the build part. You can of course wait for my report before reviewing this PR, I'll add another comment later.

@matyasselmeci
I assume someone needs to put the ID_GCTUPLOADER secret into the UberFTP repo or move/put it onto the organization level, from where it can be used in each repo below the gridcf organization, too, to make the deployment (uploading of source tarballs) working.

The relevant files (travis-ci/upload_source_tarballs.sh, .github/workflows/build-deploy.yml ) were updated accordingly, but please check for any errors. I chose uberftp as remote base path on repo.gridcf.org, so it's separate from the GCT files.

---

Don't mind errors for the respecitve test build on Travis-CI for jobs on arm64. Currently the arm64 workers over at Travis-CI do not work reliably and unfortunately Travis-CI cannot differentiate between an actual build error and an error related to the build infrastructure.

[msalle]

I'm not an expert on these steps obviously, but it looks fine to me.
One question, perhaps we should use separate ssh keys? And perhaps good to not call it ID_GCTUPLOADER although that's mostly cosmetic of course.

[fscheiner]

I'm not an expert on these steps obviously, but it looks fine to me. One question, perhaps we should use separate ssh keys?

Maybe, but if we could do with one key in the gridcf organization, that could be the easiest solution...

And perhaps good to not call it ID_GCTUPLOADER although that's mostly cosmetic of course.

...and then we could just call it ID_GRIDCF_UPLOADER?

[fscheiner]

Ok, the build works in my fork, see https://github.com/fscheiner/UberFTP/runs/4408475140.

[msalle]

I'm not an expert on these steps obviously, but it looks fine to me. One question, perhaps we should use separate ssh keys?

Maybe, but if we could do with one key in the gridcf organization, that could be the easiest solution...

And perhaps good to not call it ID_GCTUPLOADER although that's mostly cosmetic of course.

...and then we could just call it ID_GRIDCF_UPLOADER?

that sounds perfectly fine. In any case these points shouldn't block you from merging, we can always change things later.

[fscheiner]

that sounds perfectly fine. In any case these points shouldn't block you from merging, we can always change things later.

You're right. Actually I wanted to wait until the secret is in place, but as the deployment only happens when we create a tag, it won't happen (and then possibly fail) until we make the next release anyhow. But still, I'd like to keep this open until @matyasselmeci had a chance to look into it.

Maybe better to also CC to @mtru32 because he created the original workflow for the GCT.

[fscheiner]

@msalle, @matyasselmeci
Ok, time's up, I'm merging this now. But to make it fully work we still need the upload secret in place (see #17 (comment) for the proposed solution)

[matyasselmeci]

Hi all,
I think the organization-wide secret (ID_GRIDCF_UPLOADER) would be a better fit here but creating one requires admin privileges on the organization, and I don't have those.

[fscheiner]

Hi all, I think the organization-wide secret (ID_GRIDCF_UPLOADER) would be a better fit here but creating one requires admin privileges on the organization, and I don't have those.

Oh, sorry, Mat, I believed @brianhlin had admin priviilges on the organization, too, but I was wrong. I made you an owner now. :-)