add workflows for building PRs and dev-branches

[ingomohr]

There are now 3 workflows:

All three build the POM and with it the p2 updatesite.

• Build Master: Runs on pushes to master branch. Pushes updatesite build to "updatesite" branch
• Build Branch: Runs on pushes to any branch except master. Pushes updatesite build to "builds-{branch-name}" branch
• Build Pull-Request: Runs on pushes to pull-requests. Pushes updatesite to "builds-{pr-id}/merge" branch

[ingomohr]

The branch names for pull-requests are not yet "that nice". But at least you have a PR-build branch. ;)

@AObuchow Do you have suggestions on what format PR-build-branches should have?

[ingomohr]

Oh, there's another problem I just realized:

fatal: unable to access 'https://github.com/AObuchow/Eclipse-Spectrum-Theme.git/': The requested URL returned error: 403

The workflow tries to create a branch on your repo. It should create the PR-build-branch on the repo-fork which created the PR.

[ingomohr]

Oh, there's another problem I just realized:

fatal: unable to access 'https://github.com/AObuchow/Eclipse-Spectrum-Theme.git/': The requested URL returned error: 403

The workflow tries to create a branch on your repo. It should create the PR-build-branch on the repo-fork which created the PR.

Actually, I don't know yet how to solve this.
The PR is created on your Github repo, not the fork-repo, so it should be hard to push the updatesite to the fork-repo because your workflow would require permissions to write an updatesite to the fork - which it doesn't have (If logic didn't loose me somewhere)

[AObuchow]

The branch names for pull-requests are not yet "that nice". But at least you have a PR-build branch. ;)

@AObuchow Do you have suggestions on what format PR-build-branches should have?

Is the PR ID # (used in the branch name) the same as the pull request #? Eg. this pull request is #90. If it is, then this seems fine/good to me for now :) I'm used to looking up jenkins builds by PR #

[ingomohr]

The branch names for pull-requests are not yet "that nice". But at least you have a PR-build branch. ;)
@AObuchow Do you have suggestions on what format PR-build-branches should have?

Is the PR ID # (used in the branch name) the same as the pull request #? Eg. this pull request is #90. If it is, then this seems fine/good to me for now :) I'm used to looking up jenkins builds by PR #

Yes, for example, I've got this: builds-2/merge which is the branch with the build for pull request #2 in my repo.

[AObuchow]

Oh, there's another problem I just realized:
fatal: unable to access 'https://github.com/AObuchow/Eclipse-Spectrum-Theme.git/': The requested URL returned error: 403
The workflow tries to create a branch on your repo. It should create the PR-build-branch on the repo-fork which created the PR.

Actually, I don't know yet how to solve this.
The PR is created on your Github repo, not the fork-repo, so it should be hard to push the updatesite to the fork-repo because your workflow would require permissions to write an updatesite to the fork - which it doesn't have (If logic didn't loose me somewhere)

Yes your logic is correct. In all honesty - it's okay if we don't have it building on a PR as the user will have their own updatesite build on their fork (covered by your Build Branch workflow). The PR submitter could just link the updatesite for their branch on their fork in their PR (This is what I originally intended for #87 but didn't actually communicate it, my bad)

[AObuchow]

Yes, for example, I've got this: builds-2/merge which is the branch with the build for pull request #2 in my repo.

In that case, could we make it be something like builds-2/updatesite?

Also, can you also delete the travis.yml in this PR :)

[ingomohr]

Oh, there's another problem I just realized:
fatal: unable to access 'https://github.com/AObuchow/Eclipse-Spectrum-Theme.git/': The requested URL returned error: 403
The workflow tries to create a branch on your repo. It should create the PR-build-branch on the repo-fork which created the PR.

Actually, I don't know yet how to solve this.
The PR is created on your Github repo, not the fork-repo, so it should be hard to push the updatesite to the fork-repo because your workflow would require permissions to write an updatesite to the fork - which it doesn't have (If logic didn't loose me somewhere)

Yes your logic is correct. In all honesty - it's okay if we don't have it building on a PR as the user will have their own updatesite build on their fork (covered by your Build Branch workflow). The PR submitter could just link the updatesite for their branch on their fork in their PR (This is what I originally intended for #87 but didn't actually communicate it, my bad)

Ok, then I'll remove the PR workflow from the PR again.
Once we find a solution, we can easily setup a PR workflow based on the other workflows.

[AObuchow]

Ok, then I'll remove the PR workflow from the PR again.

Sounds good thank you :) Sorry for the extra/removed work for the PR workflow!

Once we find a solution, we can easily setup a PR workflow based on the other workflows.

Sounds good to me :) We need to think of how to cover this case, if its actually possible

[AObuchow]

@ingomohr looks great to me :D Any last minute concerns/thoughts before I merge?

[ingomohr]

@ingomohr looks great to me :D Any last minute concerns/thoughts before I merge?

I've tested both workflows - and if I don't miss a typo (I had "upsatesite" instad of "updatesite" at one point, but fixed it) :)
If you double-checked for typos, the PR should be good to go ;)

[AObuchow]

@ingomohr typo's can be fixed later on if I notice them ;) I quickly checked and didn't see any.
However, shouldn't https://github.com/AObuchow/Eclipse-Spectrum-Theme/blob/master/.github/workflows/maven.yml be deleted?

[ingomohr]

@ingomohr typo's can be fixed later on if I notice them ;) I quickly checked and didn't see any.
However, shouldn't https://github.com/AObuchow/Eclipse-Spectrum-Theme/blob/master/.github/workflows/maven.yml be deleted?

Yes, it should - it's in the PR if I see it correctly.

[AObuchow]

@ingomohr ah yes sorry, I meant .travis.yml

[ingomohr]

@ingomohr ah yes sorry, I meant .travis.yml

ah, that one. - For sure! ;) Gimme a sec...

[AObuchow]

It's good to merge :) The only typo I found is "Githu" repo, at the end of this line (sorry about the annoyance) :P

[ingomohr]

damn. Thank you for finding it! :)

[ingomohr]

Should've been fixed in both workflow files. :)

[AObuchow]

Perfect! Thank you so much @ingomohr this is really awesome and it's nice to be finally using your new workflow ;)