Add CI to Auto-Deploy Updatesite - even for PRs (for testing) about eclipse-spectrum-theme HOT 16 CLOSED

You don't actually need a new repository: you can put the update site on a separate branch and configure the CI to only react on pushes to master and/or pull requests for example. 😉

from eclipse-spectrum-theme.

@ingomohr That would work, although what I had in mind was that the updatesite branch would be created on the contributor's fork repo. In theory, this is already working as long as the contributor's PR is merged into their fork's master branch (as their repo will run the github action).

It might be a bit tricky to make it so that when a contributor makes a new branch on their fork, their fork's updatesite is built (so that they don't have to work on their fork's master branch). Maybe it's simple however... I haven't given it much thought yet.

Overall, the main issue/question: is it even worth having a contributor provide an updatesite for reviewers to use to test out the appearance of their fix? The reviewer would have to install the contributor's updatesite to another eclipse instance so that it doesn't replace their existing Modern Dark theme plugin (assuming the reviewer is using it). I'm not sure if this will actually save time compared to the reviewer checking out the PR via git and compiling a child Eclipse with the fix.

from eclipse-spectrum-theme.

@AObuchow of course, sorry. I got you wrong at first.

Yes, you're right. Not having the updatesite because a fork would use some other branch than masterwould maybe not cause that much difference - and maybe not all PRs require a manual integration test.

Maybe, for now, it would be enough to add some contribution-notes which state that the contributors will have an automatic updatesite on their repo as long they work on master.

from eclipse-spectrum-theme.

@AObuchow Thank you. :) - about the "all branches" thing. It should be technically possible. We could let clients decide whether they want to just build the master - or all branches (or all branches whose names match some regex). Then the workflow could just spawn/update more updatesite-xxbranches.

However, that technical approach would mean you would end up w/ 2n branches on your repo:
For every "development" branch you'd have one updatesite-<branch-name>branch, as well. ^^

from eclipse-spectrum-theme.

Ahhh yes you’re right, the newly generated update site would then become part of the PR. And the other issues you mentioned are problems...

It seems adding a prefixed updatesite-xyz repo might be the best solution for now.

Since we don’t have a big community of contributors (yet), I’m okay with leaving it how it currently is. However if you want to investigate creating an update site for each PR/commit, that’s okay too :) (if it interests you)

from eclipse-spectrum-theme.

My above idea might not work as it’d break the main repo’s (the one owned by me) update site whenever I make a new branch.

However, I could just fork my own repo like I should be doing anyhow, and the problem would be solved I think :)

Hm - having to fork your own repo doesn't sound too nice. :)

I'll be considering multi-branch updatesites, though, for the work on the action. Maybe, there's some other way to provide it w/o too many problems.

Okay sounds great :) keep me updated 😎

from eclipse-spectrum-theme.

Okay sounds great :) keep me updated 😎
I will. ;)

from eclipse-spectrum-theme.

@ingomohr with your latest merged PR, this bug might be almost (if not already) solved.

Since the PR submitter must have a fork of this projects repo, they will already have a update site generated by GitHub actions for their fork.

All that might be needed is to add a PR template that instructs the user to paste the link to the update site generated by their PR.

What do you think?

from eclipse-spectrum-theme.

@AObuchow thanks for the tag. I think we can close this now. I would have linked the PR to this issue (permissions provided) - but I also completely forgot to mention it to you. Sorry about that. :)

from eclipse-spectrum-theme.

@ingomohr no worries :)

For reference, this was essentially fixed in #58.

I'm still not entirely decided on whether or not the PR guidelines should mention to give an updatesite link from the contributor's fork. It would require me to install the plugin on another eclipse binary. This is OK and would make sure the built updatesite works correctly, however, I'm not really sure if it's less work for me compared to pulling the contributor's fork branch and testing in child Eclipse.

from eclipse-spectrum-theme.

@AObuchow Maybe we could modify the workflow to create a branch "updatesite-<pr-id>" and publish the updatesite for the pr-build there. However, we would have the problem of clearing all those branches...

Although - maybe we could automate clearing all pr-branches (for already merged PRs), as well - e.g. triggered everytime there is a push to master.

from eclipse-spectrum-theme.

@ingomohr I made a new bug for that :) If this automatic-updatesite workflow becomes used by contributors, then we can try to adjust the GitHub action to build an update site on all branches, except for when the committer is GitHub Action's itself (cause that would cause an infinite build loop). I'm not sure if this is doable however... just an idea :P

from eclipse-spectrum-theme.

@ingomohr maybe we could simplify things by just committing the update site to the branch itself? This way you wouldn’t have a bunch of updatesite-xyz branches?

It would make getting the correct update site branch URL a bit more difficult but wouldn’t make their repo have so many update site branches.

from eclipse-spectrum-theme.

My above idea might not work as it’d break the main repo’s (the one owned by me) update site whenever I make a new branch.

However, I could just fork my own repo like I should be doing anyhow, and the problem would be solved I think :)

from eclipse-spectrum-theme.

@AObuchow Yes, we could do that - however, this would lead to a cluttered commit-history - and it would require some extra-handling:

• Clutter: For each push you'd get a new commit on your branch
• Extra-Handling: For your next push you either would have to force-push or pull from remote first.

But it would solve the problem with the number of branches, yes :)

Also - this would merge their "updatesite" folder (which has been replaced by the workflow) with a PR to your original repo. That's a problem, I think. Or, is it?

from eclipse-spectrum-theme.

My above idea might not work as it’d break the main repo’s (the one owned by me) update site whenever I make a new branch.

However, I could just fork my own repo like I should be doing anyhow, and the problem would be solved I think :)

Hm - having to fork your own repo doesn't sound too nice. :)

I'll be considering multi-branch updatesites, though, for the work on the action. Maybe, there's some other way to provide it w/o too many problems.

from eclipse-spectrum-theme.